Scrum vs. Kanban Part 2/3 – Comparison
After showing the most common reasons for using agile approaches and their basic principles in the first part of this series, the second part will compare the two methodologies that are being used the most: Scrum and Kanban. This post will provide a first insight to the mindset of Scrum and Kanban teams and it will show similarities and differences of the two tools.
Comparison of Scrum and Kanban
It is said that working on projects with agile tools helps organizations to complete projects faster. This is because tools like Scrum or Kanban are process tools – they use transparency to show optimization potential and thereby help to work more effectively. An expectation to the users is to experiment by adjusting screws and by customizing the environment. Another similarity of the two tools is, that they are both not very prescriptive – they provide a framework and leave space to adjust the methodology to your conditions. Nevertheless, Scrum is more prescriptive than Kanban.
One difference between the tools is, that Scrum limits the workflow by limiting the work in progress (WIP) indirectly whereas Kanban limits the WIP directly. In Scrum the limit of WIP is managed by the workload during one iteration, or sprint. In case of the following board the maximal workload is 4 (there can be a maximum of 4 cards in the WIP column), because there are only four cards. The Kanban board is different in one little detail, the 2 in the WIP column. This limits the WIP to two simultaneous tasks. Therefore it would be allowed to start with task C immediately, but task D can only be started after either B or C are finished. The Scrum team on the other hand is allowed to start the tasks C and D immediately.
Response Time for new Requirements
Another difference of the two tools is the way they respond to new requirements. Let’s say you have the following situation in your Scrum or Kanban project and someone turns up and wants to add task E to the board. In which way do the teams react to the new card?
The Scrum team typically says something like: “Sorry, but we have committed us to A, B, C and D for this sprint. Of course you can add E to the next sprint.”
The Kanban team would say something like: “Of course you can add E to the board. But to do that you have remove either C or D, because the limit of 2 tasks is reached right now. Or you wait until we finished A or B.”
Depending on the timing for the new requirement, in Scrum the response time to new requirements can be something between the full length of the sprint and one day (in case the requirement comes up one day before the new sprint starts). Therefore the average response time is half the sprint length. In Kanban the response time is as long as it takes to get capacity available. This can be instantly (by removing another task) or the time it takes to complete another task.
The following tables will show you several similarities, differences and the basic work rules of the two methodologies to point out their strengths and weaknesses. The comparison should also help you to find the approach (or certain aspects) you can use in your projects.
|… are pull scheduling systems. This means that the team chooses when and how much work to commit to.|
|… are based on continuous and empirical process optimization.|
|… emphasize responding to change over following a plan.|
|… emphasize responding to change over following a plan.|
|… are Lean and Agile.|
|… limit WIP.|
|… use transparency to dive process improvement.|
|… focus on delivering releasable software early and often.|
|… are based on self-organizing teams.|
|… require breaking the work into pieces.|
|… help to continuously optimize the release plan based on empirical data.|
Work Rules *
The different approaches of the two tools can be shown best by showing their basic work rules.
|Split your organization into small, cross-functional, self organizing teams.||Visualize the workflow
|Split your work into a list of small, concrete deliverables. Sort the list by priority and estimate the relative effort of each item.|
|Split time into short fixed-length iterations with potentially shippable code demonstrated after each iteration.|
|Optimize the release plan and update priorities in collaboration with the customer, based on insights gained by inspecting the release after each iteration.||Limit Work in Progress (WIP) – assign explicit limits to how many items may be in progess at each workflow state.|
|Optimize the process by having a retrospective after each iteration.||Measure the lead time (average time to complete one item), optimize the process to make lead time as small and predictable as possible.|
To emphasize the differences between the two tools a bit more the following table shows some aspects that are prescribed or optional in the tools.
|Timeboxed iterations prescribed.||Timeboxed iterations optional. Can have separate cadences for planning, release, and process improvement. Can be eventdriven instead of timeboxed.|
|Team commits to a specific amount of work for each iteration.||Commitment optional.|
|Uses Velocity as default metric for planning and process improvement.||Uses Lead Time as default metric for planning and process improvement.|
|Cross-functional teams prescribed.||Cross-functional teams optional. Specialist teams allowed.|
|Items must be broken down so they can be completed within 1 sprint.||No particular item size is prescribed.|
|Burndown chart prescribed||No particular type of diagram is prescribed|
|WIP limited indirectly (per sprint)||WIP limited directly (per workflow state)|
|Estimation prescribed||Estimation optional|
|Cannot add items to ongoing iteration.||Can add new items whenever capacity is available.|
|A sprint backlog is owned by one specific team||A Kanban board may be shared by multiple teams or individuals|
|Prescribes 3 roles||Doesn't prescribe any roles|
|A Scrum board is reset between each sprint||A Kanban board is persistent|
|Prescribes a prioritized product backlog||Priority setting is optional|
As you can see, the two tools have basic similarities, but they are very different in the details. If you want to use one of them, or certain aspects, you should be aware that both are more than just boards with a lot of cards and talking about those cards. Of course, using a board is a start, but there are so much more opportunities to improve a project. If you stick to the rules and tools of the methodologies they can help you a lot. An important thing you should keep in mind is that it is not important to stick to one methodology. You are free to combine aspects, tools and rules of different methodologies to set up your project management system.
With kind regards, your SCM-Manager Universe Team