Scrum vs. Kanban

During the last years it became common to use agile methods in software development. The most widespread ones are Scrum and Kanban. The 2013 “State of Agile” survey found that a vast majority of companies (~60%) uses Scrum or Scrum hybrids. The second place is held by Kanban and “Scrumban” with more than 10%. Compared to the survey from 2012, Kanban experienced the highest increase in usage. That is why we want to compare those two methodologies.

This post will be about Scrum and Kanban in general. For detailed information about the tools visit for example or

Why Agile?

What are the reasons to use agile approaches in projects? Let’s answer this question with some figures: The 2013 “State of agile” survey found that the greater majority of people using the agile approach had a faster completion time (~73%) whereas only 6% claimed that projects took longer. Before people start working with agile tools they have expectations about the benefits, and after the projects completion they can say whether their expectations were met, or not. The following image shows the importance of several aspects and whether they improved by using agile methodologies or tools.

Based on the graph above it is important for 75% of the participants of the survey to accelerate the “time to market” (blue bar). For 83% of projects this aspect improved by using agile methodologies (yellow bar). This behavior can be seen for all of the shown aspects: important aspects improved for the vast majority of projects. What the survey didn’t talk about, are the reasons why for some participants those aspects didn’t improve.

The Agile Manifesto

There are a lot of agile methodologies and tools that have similarities and differences. All are based on the same principles, which are written down in the “Manifesto for Agile Software Development“. The manifesto states that certain aspects are more important than others and that it is necessary to internalize those facts.

For example the manifesto says that responding to change is more important than following a plan. An important factor for the success of agile projects is that the participants have the right mindset to work in an agile project environment. Another important advice is that you shouldn’t limit yourself to just one tool. Combine aspects from different tools that fit your needs, but be aware of the fact that you are combining several tools.

Since most agile methodologies are based on the same principles, many of them have quite similar approaches. Some of them use a lot of restrictions, others leave a lot of freedom. The Agile Manifesto states the basic principles and each methodology uses its own set of tools and rules. The challenge is to find the methodology and tools that best fit your needs. To support this we want to compare the two most widespread methodologies in more detail.

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. They expect users 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 progess (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 Srum or Kanban project and someone turns up and wants to add “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 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 to 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.

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

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

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

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 prescribedEstimation optional
Cannot add items to ongoing iteration.Can add new items whenever capacity is available.
A sprint backlog is owned by one specific teamA Kanban board may be shared by multiple teams or individuals
Prescribes 3 rolesDoesn't prescribe any roles
A Scrum board is reset between each sprintA Kanban board is persistent
Prescribes a prioritized product backlogPriority setting is optional

As you can see, the two methodologies have basic similarities, but they are very different when you look at the the details. Those details become more clearly if you look at a less trivial example, that’s why we want to do exactly that.

A less Trivial Example

The following example represents a project that is less trivial than the one in the second part of this series. There is a product backlog containing several tasks and a production process that consists of several steps.

  • In case of Scrum the team is in the first sprint, which consists of the tasks A, B, C, D, E and F. A is already done, B to E are at the moment in progress and F is still to do. During the upcoming sprints the team will commit to the tasks G to N.
  • The Kanban board consists of the backlog from which maximal 2 tasks can be selected for priorization. The development section allows max. 3 tasks at once (tasks from both columns – ongoing and done – count). After the development the features need to be tested and after that they will be in the production environment and are thereby done. You can see that the board represents the different states of the production process.

The Scrum board will be reset after each sprint, whereas the Kanban board is persistent.
After a few Scrum sprints or simply after some time the two boards could look like this:

Note: For Kanban it is not necessary that there is a maximal amount of tasks for each column.
The Kanban board, which contains more columns than the Scrum board, can help to optimize the process steps, because it is necessary to think about them in order to draw the board. It can also be very helpful to optimize the amount of allowed cards per column, because this can reveal bottle necks. The Scrum board and the partition of tasks into sprints helps to organize tasks and to think about reasonable packages. But remember, it is always possible to combine aspects of different methodologies and tools to find the board, rules and tools that fit your project best.

Other Agile Tools and Methodologies

Besides the two tools Scrum and Kanban there is a huge number of other agile tools and methodologies that serve as an inspiration for you. The more you read about them, the more you will see that they are based on the same principles (which are stated in the agile manifesto) and that some use the same approaches and methods. Here is a short list of some wide spread approaches that you could take a look into.

  • Extream Programming (XP)
  • Lean Software Development
  • Feature Driven Development (FDD)
  • Crystal Family
  • Test Driven Development (TDD)


A Kanban board represents the workflow of a project whereas a Scrum board always consists of the same columns. Another big difference is that it is possible to limit the number of cards in certain columns when using Kanban while Scrum limits the WIP by restricting the number of cards in the Sprint Backlog.
Besides the two methodologies that were presented here there are numerous other agile approaches. Some of them are based on Scrum or Kanban. A very widespread approach is a combination of Extream Programming and Scrum, because both supplement each other very well. It’s up to you to find the methodologies, tools and rules that you want to use to accomplish the aims of your projects. Since there is no “one fits all” for all projects you have to experiment and try variations.

Share this article


  1. Great article!!! You have clearly described the fundamental differences between Scrum and Kanban. Clearly, choosing between Scrum and Kanban depends on certain factors. One of the criteria for selecting an agile tool in terms of Kanban or Scrum can be the time required. One of these methodology works well when there is a shortage of time in terms of deadlines; the other one works well in situations where more time is required to carry out tasks when a diminutive iteration cannot satisfy the work. I read this from an article that explained how much alike and different Scrum and Kanban are –

Comments are closed.

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