When to use Kanban vs Scrum
If Scrum is the most widely used Agile methodology, Kanban is probably in second place. It’s old, it’s elegant, it’s simple and it works. This article will explain when to use Kanban vs Scrum. And explain the similarities and differences between Scrum and Kanban. It really depends on what type of work you are doing.
Some people use straight-out Kanban, no Scrum at all. Especially if they are not doing software development, or are doing small enhancements or fixes. A lot of people use Kanban in combination with Scrum. They sometimes call this “Scrum-ban”. Some people use just a few ideas from Kanban, some use a 50/50 mix of the two.
Kanban is neat like that. You can easily add, pick and choose bits you like and leave bits you don’t.
Scrum or Extreme Programming aren’t flexible like that. They don’t tend to work well if you just take a couple of random bits. They are a coherent system. Kanban is not really a coherent system, it is just a set of principles for visualising and improving work. Pick the ones you like. Or use them all!
First, let’s go through the main differences between them. Then we will know when it is better to use Kanban vs Scrum.
Scrum is all about iterations
Scrum is all about iterations
The main focus in Scrum is on iterations. An iteration is a short fixed unit of time. Scrum calls these iterations “sprints”. A sprint is usually two, three or four weeks long. Your sprints all have to be the same length. You can’t have a slightly longer sprint here and a shorter sprint there. That’s cheating.
The point is to get into a predictable pattern of delivering work. The team performs frequent planning and frequent reviews and retrospectives. This enables the team to predict and plan the work that will get done over the next couple of sprints.
What is Kanban in agile
Kanban is a framework for visualising and improving the flow of work. It is based on a set of older Japanese concept that formed part of the Toyota Production system. Which is also known as Lean Manufacturing. Many people use some of the ideas on Kanban on top of whatever main framework they are using. That could be Scrum, or Waterfall / Prince2, or anything.
This article will talk about using “pure” Kanban, i.e. just the ideas from Kanban. But not combined with another framework.
Kanban is about work states and flow
Lean Kanban University are the main Kanban group in the world
In “pure” Kanban, there are no sprints. There are no iterations. It’s not so much about time and planning, it’s more about work and flow. The focus in Kanban is on breaking up and visualising small pieces of work. You then map the work items onto specific work states.
Try to get few work items in any particular state, and few work items as possible blocked. You can also impose “WIP limits” (work in progress limits) on each state. This means you can’t have more than a certain number of items in a particular state at once. The objective is to have a smooth flow of work across these states.
Scrum is good for progress and planning
Scrum is a good framework for feature development work. For work where you have a bunch of features you need to build and you need to plan roughly how long they will take to build, and when they might be finished.
Scrum is about short planning and feedback cycles
Scrum uses fixed sprints so you can measure your progress and determine your velocity. The velocity will help you plan how long it will take to finish all the work. Remember, velocity is for a team to do it’s own internal planning, not for a senior manager to measure “productivity”.
There are also the Scrum ceremonies, which help keep the team focused on the sprint plan and sprint goal. And provide a short feedback cycle.
So in summary, scrum is well suited to feature development work because:
- the work is in large vague chunks that you can then break down into smaller chunks
- the work forms part of an even bigger series of long-term goals (“releases” or “horizons”)
- regular fixed timeboxes let you measure your rate of progress
- fixed timeboxes and a rate of progress mean you can plan towards the big long-term goals.
Kanban is good for flow and throughput
Kanban is well suited for work where there is no big backlog of features to go through. Rather, the focus is on quickly completing small pieces of work as they come up.
A common example of this is a team assigned to fixing production incidents. Kanban works really well here because:
- the work pops up in front of the team (i.e. supply based) rather than pulled in from the team (i.e. demand based)
- the work is in small discrete pieces
- there is no overall long-term objective or goal to reach
- planning is unimportant or irrelevant.
When not to use Kanban
I think the basic ideas of the Kanban method (around visualsing work, improving flow and reducing WIP) are great and apply pretty much anywhere. But I would not recommend “pure Kanban” (i.e. no other framework like Scrum) if you are doing complex product work. Where you need to plan, gather feedback and use that feedback to inform your next planning cycles.
Kanban doesn’t really tell you how to do that. But Scrum has great answers for how to operate there.
What if you want to use both?
So maybe you’re still unsure when to use Kanban vs Scrum. And you decide you like want to use both.
Kanban boards (aka VMB) are a key part of Kanban
Well the good news, you can. In fact, most people do. Most agile software development teams use Scrum, and a lot of them use at least some (but not all) of the ideas from Kanban.
The common one is of course a physical kanbanb board (or VMB), including swimlanes . They are so common that I take them for granted, and often forget that Scrum doesn’t mention them at all! It is also common practice to use some other Kanban ideas involving VMBs like avatars, and marking blocked stories.
The Scrum community has started embracing Kanban more. For example, Scrum.org published the “Kanban Guide for Scrum teams“. So check that out if you haven’t seen it.
So when to use kanban vs scrum?
In summary, the quick “scrum vs kanban cheat sheet” is:
- use Scrum (or something like it) for feature-driven work with big release goals or milestones
- use Kanban (or something like it) for incoming small pieces of work such as defect fixes or small enhancement requests
- but feel free to combine them, like taking Scrum but applying the great Kanban ideas around Visual Management Boards and mimising WIP.
I hope this helps clear things up!
