What is Best, Scrum or Kanban?

What is best, Kanban or Scrum? Because I can't make up my mind, I decided to write a single article in two parts—one where I wear the "I love Kanban" hat and one where I'm wearing an "I love Scrum" T-shirt.

I have for some time been thinking, what is best, Kanban or Scrum. I can't make up my mind so I decided to write a single article in two parts, one where I wear the "I love Kanban" hat and one where I'm wearing an "I love Scrum" T-shirt.

First I would like to tell you shortly what Scrum and Kanban is.

Scrum in 1 minute

Scrum is about getting back to the time when the company was small and everything was easy and ran smoothly. Back then projects were small, teams were small, releases were small and communication was easy. Best of all, we were efficient.

In Scrum we split our big project into small projects as we work on timeboxed iterations called sprints. We split our big team into small teams (still with all the skills we need) and launch often. If we are more than 20 employees we probably have a problem knowing what the other departments and customers are needing so let's bring someone into the team that can represent them. To help communications from the team to the rest of the company we have our plan and current status visible. The plan is called the sprint backlog and the status is shown on the scrum board. Here is an example:



The person we brought in to represent all stakeholders is called product owner and is responsible for prioritizing a list with features that will be developed for the product in the future. This list is called the product backlog.

To make Scrum a process we add some small but necessary meetings: a planning meeting, daily synchronizing meeting and meetings to improve product and process. We decide the length of our iterations and aim to deliver something valuable after each iteration.



Kanban in 1 minute

Scrum is simple but Kanban is even simpler. Just visualizing your workflow and limiting demand to capacity is enough to call it Kanban.

Let's start by looking at the roots of Kanban. It's a way, invented and used by Toyota, to get a good flow of parts to their plants. Kanban is just a card attached to the part and when the part is used the Kanban is sent as a request to the supplier for more parts. The physical card is actually sent to the supplier who is attaching it to the next pert sent. Since the cards are re-used and no new cards are entered in the circulation Toyota limits the number of parts in stock and at the same time make sure new parts are ordered as soon as they are needed.



In software development Kanban is a limited promise of work. A Kanban board is a number of placeholders for work to be done. A typical Kanban board can look like this.



Each team has decided their limit and drawn as many squares as the limit allows them to. Whenever a task is done it will be moved to the next group if and only if they have free Kanban squares. Else the task is stuck. If there is nothing more to do we have a problem with the flow and we need to work together to solve what is stopping us.

While Scrum is focusing on delivering on commitment Kanban is focusing on getting a smooth flow.

In common for Scrum and Kanban

There are a lot of similarities between Scum and Kanban. Some examples are:

  • A strict prioritization (it's obvious what to do next)
  • Self-organizing teams (see below)
  • Transparency (show what you've done, your current status and what's next to do)


AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.