Or “When Should We Use Kanban Instead of Scrum?”
Or “When Should We Use Scrum Instead of Kanban?”
The two most popular Team practices are Scrum and Kanban. People often wonder whether one is better than the other, or whether one should be applied over another. This page will help you think through the ideas.
As you can see, Kanban is very lightweight and requires a lot of (self-)discipline to implement on a team. The specific practices that Kanban teams might use include:
For folks that are into the details of these two methods. They clearly come at the problem of managing knowledge work from different perspectives. The following table provides a clear breakdown of these differences:
| Scrum | Kanban |
|---|---|
| Time-boxed iterations prescribed | Time-boxed iterations optional. * Can have separate cadences for planning, release, and process improvement. * Can be event driven instead of time-boxed. |
| Team commits to a specific amount of work for this iteration (Sprint) | Team commits to work when it is brought to the board for execution |
| Uses velocity as default metric for planning and process improvements | Uses lead time as default metric for planning and process improvements |
| Cross functional teams prescribed | Cross functional teams optional * Specialist teams allowed |
| Items must be broken down so they can be completed in an iteration | No item size is prescribed although small(-er) sized work is highly recommended |
| Burn down chart is prescribed | No diagram type is presecribed |
| “Change agent” is “commitment” | “Change agent” is “WIP limits” |
| WIP limited indirectly * Per iteration | WIP limited directly * Per workflow state |
| Estimation prescribed | Estimation optional |
| Cannot add items to ongoing iteration | Can add items whenever capacity is available |
| Prescribe 3 roles * Product Owner * Scrum Master * Team | No prescribed roles |
| Prescribes 4 events * Planning * Daily Scrum * Review * Retrospective | No prescribed events |
| Scrum board is reset between each iteration | Kanban board is persistent |
| Prioritized backlog is prescribed | Prioritization is optional |
If you treat Kanban and Scrum as if they are competing approaches, or adopt a textbook approach to their implementation, then the advice to choose one approach over the other usually breaks down as follows:
| Question | Kanban | Scrum |
|---|---|---|
| Primary Consideration | ||
| * Work for the team is more than 50% demand driven (team's priority is responsiveness) | X | |
| * Work for the team is most project driven (team's responsibility is predictability, forecasting and productivity) | X | |
| Secondary Consideration | ||
| * Team questions value of estimation and planning | X | |
| * Team struggles to break items into small pieces | X | |
| * No or low appetite for significant process change | X | |
| * Some or high appetite for significant process change | X | |
| * Team members have significant self-discipline | X | |
| * Team members have limited self-discipline | X |
Some people feel like Kanban is easier to implement and so opt for that. The reality is that the WRONG reason to implement Scrum is because the Team is simply unwilling to do Scrum-like events or find that they cannot finish a Story in one Iteration.
A notes on this criterion. Many teams whose work is the result of a ticketing system assume that all their work is demand driven, and that Kanban is therefore their only option. This is a problem in that if the team can plan work, they usually are also able to deliver better and faster over time.
Experience has shown that work coming from the ticketing system does not mean that we must treat every work item as interrupt-driven and therefore you are unable to plan it. For example, teams that are pure production support have different classes of incoming problems and so can vary how quickly you would need to respond to that problem. A production site is down request is going to need a more urgent response than say a minor defect because of a workflow problem. This gives as an option to plan more items and would mean that Scrum practices are useful. For example, if we can suggest to the customer “that they wait for (on average for a 2 week Iteration) 1 week for us to work this defect” then we can treat this as an input into the next planned Sprint (iteration) in a Scrum implementation.
In some instances up to 65% of the incoming work for a Team can be treated this way.
In some ways the discussion about whether you use EITHER Scrum OR Kanban is misleading. Like all agile approaches the best idea is to leverage Kanban and Scrum to improve how you deliver value. Scrum teams can benefit from ideas like understanding the workflow, WIP limits, classes of service. Kanban teams benefit from an understanding of the purpose of Scrum events, roles, and artifacts and incorporate some or all of them into their practice.
Here are some more specific approaches people have tried: