When to use kanban vs scrum

when to use kanban vs scrum

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. A lot of people use Kanban in conjunction 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, and some people just use straight-out Kanban. No scrum at all. This article will explain when to use Kanban vs Scrum. It really depends on what type of work you are doing.

However, a lot of teams just use a couple of the basic ideas from Kanban, rather than the whole thing. 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.

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.

Kanban is about work states

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

  • the work is in large vague chunks that can then be broken down into smaller specific chunks
  • the work generally 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 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:

  • 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, that aren’t usually related to any other pieces of work
  • there is no overall long-term objective or goal to reach
  • planning is unimportant or irrelevant.

What if you 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 they are not mentioned anywhere in Scrum! It is also common practice to use some other Kanban ideas involving VMBs like avatars, and marking blocked stories.

So when to use kanban vs scrum?

In summary, you should:

  • 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, especially taking Scrum but applying the great Kanban ideas around Visual Management Boards.

I hope this helps clear things up!

This article was originally posted on my blog, www.extremeuncertainty.com