Scrum vs. Kanban

by on August 10, 2010 · 11 comments

When inflexible and wasteful processes are making your organization inefficient, it’s time to introduce agile methodologies. Scrum vs. Kanban then becomes an essential question: Which one is better suited for my own situation?

Scrum – A Fundamental Shift

Scrum is a well defined process framework for structuring your organization. Introducing Scrum is quite a change for a team not used to agile methodologies: They have to start working in iterations, build cross-functional teams, appoint a product owner and a scrum master, as well as introducing regular meetings for iteration planning, daily status updates and sprint reviews. The benefits are well understood: Less superfluous specifications and less hand overs due to cross-functional teams, more flexibility in roadmap planning due to short sprints, etc. Switching your organization to use Scrum is a fundamental shift which will shake-up old habbits and transform them into more effective ones.

Scrum Leverages Commitment As Change Agent

The initial introduction of Scrum is not an end in itself of course. Working with Scrum you want to change habits inside your team: Take more responsibility, raise code quality, increase speed. As your teams commit to sprint goals, they are intrinsically motiviated to get better and faster in order to deliver what they promised. Scrum leverages team commitment as change agent. It’s amazing to see how much teams demand from themselves – often way more you as a manager ever dared ask for.

Kanban – Incremental Improvements

Kanban is way less structured than Scrum. It’s no process framework at all, but a model for introducing change through incremental improvements. You can apply Kanban principles to any process you are already running (even to Scrum ;-). In Kanban, you organize your work on a Kanban Board. There you have states which every work item passes through from left to right. You pull your work items along through the in progress, testing, ready for release, and released columns starting from the right hand side based on the allocated capacity of each of the columns. And you may have various swim lanes – horizontal “pipelines” for different types of work. The only management criteria introduced by Kanban is the so called “Work In Progress (WIP)”. Nothing else needs to be changed to get started with Kanban.

Kanban Leverages Work In Progress (WIP) Limits as Change Agent

For every column (state) on your Kanban board you should define a “Work In Progress”-Limit (WIP Limit). The WIP limit tells you how much work items are allowed to stay in a certain state. If the state is “full”, no new work can enter that state. The whole team has to help clear the filled up state first. That way your team will find out about bottlenecks in the progress simply by looking at the Kanban Board and is challenged to change the way they work to avoid such bottlenecks in the future. In that way, the WIP limit acts as change agent in Kanban.

Scrum vs. Kanban

Looking at both agile methodologies it should be more clear what to introduce when: If your organization is really stuck and needs a fundamental shift towards a more efficient process, Scrum seems to be more appropiate. If you already have working processes, which you want to improve over time without shaking up the whole system, Kanban should be your tool of choice.

Did you enjoy this article? Get new articles for free by email:


  1. says

    Matthias, that does simplify things very nicely. Thanks for the overview.

    One very visible and notable difference is that Scrum has the Sprint Planning meeting and the Spring Retrospective. They demand customer involvement in a very pointed way. It’s rather easy for the customer to ignore “the board” with the attitude that it’s just for the geeks to play with. The customer really can’t ignore Scrum because it starts and ends with the customer.

  2. says

    Mark, thanks for pointing this out. It’s a good example showing that Kanban is not a process framework like Scrum. Exactly such things like customer involvement (and many more) have to be defined separately. It’s even a good idea to run Scrum and improve it over time using Kanban (sometimes this is called “Scrumban”)

  3. says

    a very nice and interesting summary. The introduction of Kanban to our company worked smoothly and the result has been efficent as expected. There was no change management needed as this is easy to implement and to understand with an immediately outcome of results. Have you also some more experience and some advise how to efficiently upgrade from Kanban to Scum (Kanbum?)?

  4. says

    Hi Matthias,
    Enjoyed reading this summary of Scrum and Kanban. It’s nice to see concise well written paragraphs.
    Wanted to point out though that Kanban is a pull system versus a push system, instead of, “You start left with the Backlog, and push your work items along through the in progress”, it should read, “You start on the right hand side of the board and pull work items through based on the allocated capacity”.
    Dominica DeGrandis

  5. says

    Hi Matthias,

    I have published a similar post before, “Scrum to Kanban“. The post lists the flaws in Scrum, and then talks about Kanban and how to migrate from Scrum to Kanban.

    I think your article is excellent as a comparison between the two, and I would like to republish it on PM Hut. Please either email me or contact me through the “Contact Us” form on the PM Hut website in case you’re OK with this.