October 15, 2014 / by Daniel Huchthausen / In Methods

Scrum vs. Kanban Part 2/3 - Comparison

+++This post was migrated from our former blog about SCM-Manager Universe. Therefore, the design is slightly different and some information might not be 100% applicable to Cloudogu EcoSystem. So don't be alarmed; enjoy reading.+++

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.

Similarities *

… 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.

Scrum Kanban
Split your organization into small, cross-functional, self organizing teams. Visualize the workflow
  • Split the work into pieces, write each item on a card and put it on the wall.
  • Use named columns to illustrate where each item is in 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.

Differences *

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.

Scrum Kanban
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

Bottom Line

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

Daniel Huchthausen

- Consultant -

When he is not exploring the wilderness, Daniel keeps himself busy with topics such as quality assurance, testing and PM methods.

©2018 Cloudogu GmbH. All rights reserved. Legal Notice | Privacy Policy

Cloudogu™, Cloudogu EcoSystem™ and the Cloudogu™ logo are registered trademarks of Cloudogu GmbH, Germany.