Comparing Kanban To Scrum

| by Mike Bria Follow 0 Followers on May 13, 2009. Estimated reading time: 3 minutes |

Kanban has been gaining serious interest as a valid approach to implementing agile for your development organization. As such, many people are asking the question "how does Kanban compare to Scrum?". Henrik Kniberg has taken a stab at answering this question.

Henrik Kniberg has recently published a draft version of a "practical guide" comparing Kanban and Scrum. With this concise article, Kniberg presents an outline of the ways Kanban and Scrum are similar, and how they differ.

He starts the article with this quicklist view of each methodology:

Scrum in a nutshell
Split your organization into small, cross-functional, self-organizing teams.
Split your work into a list of small, concrete deliverables. Assign someone to be responsible for that list and to sort the list by priority. The implementation team estimates the relative size of each item.
Split time into short fixed-length iterations (usually 1 – 4 weeks), with potentially shippable code demonstrated after each iteration.
Optimize the release plan and update priorities in collaboration with the customer, based on insights gained by inspecting the release after each iteration.
Optimize the process by having a retrospective after each iteration.

For more details check out “Scrum and XP from the Trenches”. The book is a free read online. I know the author, he’s a nice guy :o)

Kanban in a nutshell
Visualize the workflow
  • Split the work into pieces, write each item on a card and put on the wall
  • Use named columns to illustrate where each item is in the workflow
Limit WIP (work in progress) – assign explicit limits to how many items may be in progress at each workflow state.
Measure the lead time (average time to complete one item, sometimes called “cycle time”), optimize the process to make lead time as small and predictable as possible.

For more details check out Karl Scotland’s intro:

Over the next 20-some pages Kniberg goes into detail with his comparison, then presents this summary of his thoughts at the end of his article:

  • Both are Lean and Agile
  • Both use pull scheduling
  • Both limit WIP
  • Both use transparency to drive process improvement
  • Both focus on delivering releasable software early and often
  • Both are based on self-organizing teams
  • Both require breaking the work into pieces
  • In both cases the release plan is continuously optimized based on empirical data (velocity / lead time)
Scrum Kanban
Timeboxed iterations prescribed. Timeboxed iterations optional. Can have separate cadences for planning, release, and process improvement. Can be event-driven instead of timeboxed.
Team commits to a specific amount of work for this iteration. Commitment optional.
Uses Velocity as default metric for planning and process improvement. Uses Lead time as default metric for planning and process improvement.
Cross-functional teams prescribed. Cross-functional teams optional. Specialist teams allowed.
Items must be broken down so they can be completed within 1 sprint. No particular item size is prescribed.
Burndown chart prescribed No particular type of diagram is prescribed
WIP limited indirectly (per sprint) WIP limited directly (per workflow state)
Estimation prescribed Estimation optional
Cannot add items to ongoing iteration Can add new items whenever capacity is available
A sprint backlog is owned by one specific team A kanban board may be shared by multiple teams or individuals
Prescribes 3 roles (PO/SM/Team) Doesn’t prescribe any roles
A Scrum board is reset between each sprint A kanban board is persistent
Prescribes a prioritized product backlog Prioritization is optional

If you've asked this question yourself, or needed to answer it for someone else, you should take some time to read Kniberg's Kanban vs Scrum article.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

French translation by Fabrice AIMETTI

Please, find the french translation of excellent Kniberg's "Kanban vs Scrum" article on Kanban-vs-Scrum-French.

Why not CCPM? by Cloves Almeida

Critical Chain Project Management is a "straight to project" implementation of TOC and Lean philosophy. It uses much of lean principles like Kanban, but deliver the concepts more practically.

Also, the book, by Eli Goldratt, is a fun read. :)

Re: Why not CCPM? by Cloves Almeida


I've read TFA now, and I believe the "support and maintance" work best fit the model proposed in "Drum-Buffer-Rope" (DBR).

Comparative? by Adron Hall

Scrum still sounds like its for revisinist Waterfall practitioners than Agile"ish" in nature. All of thise time boxing, scheduling, planning, and other errata ends in BDUF more often than not. Kanban however, the projects I know of, rarely fall into the BDUF trap and rarely get bogged down or frustrated as many do with Scrum.

...any other personal insights or experiences out there with these?

Re: Comparative? by Dave Nicolette


When you say "sounds like" it gives the impression you haven't worked with Scrum or Kanban before, and when you say "more often than not" it gives the impression you're speaking from experience. These sound like mutually-exclusive conditions. Which one is true?

I think it goes too far to say Scrum encourages waterfallish thinking and outcomes, and it goes too far to say Kanban solves these problems. A process or framework or methodology doesn't "solve" anything. The outcomes people achieve result from the choices they make. Having a process or framework in place that helps guide people toward good choices is, of course, desirable and useful, but the process itself cannot be blamed for poor outcomes or praised for good ones. Every process is "only" a tool. I use quotation marks around "only" because we have to have the right tools for the job, after all. I just mean to say we must not become slaves to our tools, and we must not expect that because we can spell "Scrum" or "Kanban" or any other word that we can put our feet up and relax while we wait for our Magic Process to get the work done.

I think Scrum represents early thinking about "agile" methods that was driven by the status quo in most large organizations at the time. The status quo today is different. More organizations are ready to adopt the level of change that is required to move to a Kanban process, or at least to begin to apply lean thinking. In my view, Scrum "forces" people to be accountable for particular aspects of software delivery by defining specific roles, and "forces" people to deliver incremental results regularly and to reflect on their work regularly. This is appropriate in an environment where these concepts are not part of the culture. Once the organization has matured to the point that people no longer have to be "forced" to do these things, then people may be able to see the way to Kanban. Until they learn to think in terms of ideas like value stream, continuous flow, pull, and waste, it's hard for people to understand why they should consider something like Kanban. It's easy for people to stick a few cards on the wall, walk around repeating "Kanban" or "Scrum" or some other incantation and not really change the way they think or the way work flows in their organization. If people choose to do that, it isn't Kanban's fault, and it isn't Scrum's fault, either.

Personally, I haven't seen Scrum lead to BDUF. I have seen people say they were implementing Scrum while continuing to practice BDUF - their own old habit, their own choice. Kanban would not automagically save them from their own habits and choices. We've got nothing, as a community or as a profession, as long as we persist in joining "camps" that defend their favorite magic-bullet-of-the-moment and disparage others who have found other ideas useful in particular contexts. There are many valid and practical ideas that help us deliver value effectively. I'm not surprised at all to see advancement beyond the initial concepts of "agile." I won't be surprised when we discover the next steps beyond Kanban, either. It's a major step forward, but it's not the end of the journey.

Re: Comparative? by Adron Hall

"When you say "sounds like" it gives the impression you haven't worked with Scrum or Kanban before, and when you say "more often than not" it gives the impression you're speaking from experience. These sound like mutually-exclusive conditions. Which one is true?"

I'm experienced in Kanban and experienced in hearing about Scrum. I haven't done Scrum, but similar activities.

You are right about a methodology not solving process problems. It is the activities that the methodology pushes that solve the problems, through employee work activity. Thus I was merely stating by association, which is true enough.

Over Waterfall I'd take either system, but it looks like by observation and the projects I've seen over the last 15 years that Kanban does a lot more to solve the myth of scheduling and maintaining real velocity. Scrum doesn't address scheduling, instead new names are just applied to the process and I'd suspect (no evidence yet) that project managers would end up with the same bad scheduling numbers.

Iterations are great, but workflow and maintaining velocity would be a higher priority to me. Most teams are going to be able to maintain velocity easier without stop and go iterations and move much faster just working from the backlog of the Kanban.

Just my 2 cents, but I'd go head to head against any other team working Scrum any day utilizing Kanban.

Re: Why not CCPM? by Olivier Gourment


Re: Comparative? by Phil Vuollet

This has been out here for a long time, but was recently referenced by a recent blog I just read. Interesting points about Scrum. I'm finding that more and more I want to release something once its complete rather than waiting til the end of the cycles. I'd rather not batch a bunch of things into a 2 week cycle just because they fit either. I'd rather be batching work together that makes sense together and release whenever its ready. Sounds maybe more like Kanban.

Last point, just a quick reminder that avoiding BDUF is not the same as NODUF. Need some design up front. So how about SDUF?

Scrum vs. Kanban vs. Scrumban vs. Waterfall in practise by Dustin Moris Gorski

I blooged this topic, the differences between agile frameworks and when one or the other makes more sense last year which might help to decide which tool is a good fit for a given project or team:

It doesn't really matter which one you choose by Dennis Nerush

About two years ago I came to an interesting conclusion — it doesn’t matter how you call it as long as you apply the right principles.
You can read more about why here:

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

10 Discuss

Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you