If Scrum is the most widely used Agile methodology, Kanban would have to be second place. It’s old, it’s elegant, it’s effective, it’s simple and it works. This article will explain when to use Kanban vs Scrum. 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.
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.
In Kanban, there are no sprints. There are no iterations. It’s not so much about time and predictability, it’s more about work. 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 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. It uses fixed sprints so you can measure your progress as you go 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”, right?. Right.
So in summary, scrum is well suited to feature development work because:
Kanban is well suited for work where there is no big backlog of features to go through. Rather, the focus is on quickly burning through 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:
So maybe you’re still unsure when to use kanban vs scrum. And you decide you like want to use both. 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 the swimlanes on a VMB. 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.
In summary, you should:
I hope this helps clear things up!