During the last years it became common to use agile methods in software development. The most widespread ones are Scrum and Kanban. The “State of Agile” survey for 2020 for example found that a vast majority of companies (~75%) uses Scrum or Scrum hybrids. The second place is held by Kanban and “Scrumban” with about 15%. 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 www.scrum.org or http://limitedwipsociety.ning.com/.
Why Agile?
What are the reasons to use agile approaches in projects? Let’s answer this question with some figures: The State of agile survey found that the greater majority of people (70%) using the agile approach improved their ability to manage changing priorities. 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. (The data is from the 8th State of Agile survey, but the results stayed almost the same over the years.)
You can see that 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.
There is a large number of agile methodologies. Many of them have quite similar approaches and use the same principles. Some of them use a lot of restrictions, others leave a lot of free space. The Agile Manifesto states the basic principles and each methodology uses it’s own set of tools and rules. The challenge is to find the methodology and tools that best fit your needs.
Comparison of Scrum and Kanban
After showing the most common reasons for using agile approaches and their basic principles, we can now compare the two methodologies that are being used the most: Scrum and Kanban. We want to provide a first insight to the mindset of Scrum and Kanban teams and show similarities and differences of the two tools.
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 continuously adjusting to chaning circumstances 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.
Workload
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.
Comparison
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
Both…
… 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. 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. | 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. |
| 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 |
How to choose between Scrum and Kanban?
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.
So how do Scrum and Kanban look in real life? We will show an example of how projects proceed on the different boards. This again shows some advantages and disadvantages of the two methodologies and can help you to find the solution for your own project.
Examples of Scrum and Kanban in use
The following example represents a project that is less trivial than the one in the previous paragraph. 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.
- Extreme Programming (XP)
- Lean Software Development
- Feature Driven Development (FDD)
- Crystal Family
- Test Driven Development (TDD)
Bottom line
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 Extreme 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.
Top comments (0)