Both Scrum and Kanban are well-known Agile software development methodologies. They are both flexible processes that promote small, iterative changes and promise enhanced productivity and a better quality of the final product. Of course, they both have their advantages and success stories when adopted in software projects therefore, the decision of which framework to embrace usually belongs to the development team. In the followings I will go through some of the similarities and differences between the two frameworks as they were presented by Henrik Kniberg in his book “Kanban and Scrum, making the most of both”.
So, as I already stated, both processes follow the Lean and Agile principles, are empirical development methods and approach large work packages in the same manner: by dividing the total amount of work into small, manageable work items and delivering them as early and as often as possible. Both methodologies use pull scheduling and set limits on the WIP (work in progress) but, while Scrum indirectly limits the WIP by means of time units, or iterations, Kanban limits the WIP directly, per workflow state. Nevertheless, transparency is ensured by both methodologies with the purpose of improving and optimizing the process.
In terms of differences, Scrum is more prescriptive compared to Kanban. For example, a striking difference is that while Scrum requires specific roles (Product Owner, Scrum Master and team), Kanban prescribes none. Also, in terms of teams, Scrum prescribes cross-functional teams but Kanban sets this as optional and allows as well specialists teams. Unlike Scrum, that uses and advises for time boxed iterations, Kanban can be very much event driven and have separate cadences for planning, release or improvement. Moreover, both estimation and commitment are optional in Kanban while in Scrum the teams must always break down the items, estimate them and commit to a specific amount of work during each iteration. Another difference lies in the boards: while the Scrum board belongs to one team only and resets at the beginning of each sprint, Kanban boards are persistent and can be owned by several teams.