This is my summary of Henrik Kniberg’s “Kanban and Scrum – making the most of both”, a session I attended at ScanDevConf 2010. Please understand that, except for the notes at the top and bottom, this post reflects the opinions of the speaker, not me.
A supershort summary of Scrum:
- Split your team into small parts
- Split your product into small parts
- Split your time into small parts
… i.e. instead of a large team working on a large product for a long time, you have small teams working on small pieces of the product for short periods of time.
Kanban is:
- a signalling system
- with visible indicators
- that are limited in number.
Kanban in software development includes:
- visualizing the workflow (with columns on a whiteboard)
- visualizing the stuff in workflow
- limiting work in progress (WIP)
- measuring and optimizing flow
- explicitly defining your policies – the definition of done, WIP limits etc
How do the two differ?
- Scrum has more rules than kanban. On a scale from prescriptive to adaptive, the order would be
RUP > XP > Scrum > Kanban > do whatever works. - Scrum defines roles while Kanban doesn’t. In practice they might look the same.
- Both are empirical and measure things (velocity, lead time, quality etc). Kanban gives you more knobs to twiddle to change the outcome.
- Scrum has one cycle: planning and committing, releasing, and retrospectives, all three are done on the same cycle. Kanban does not tie these together; you could have a different cycle for each one.
- In Scrum, items must fit within a sprint. Kanban allows long-running tasks, limited only by WIP limits.
- Both limit WIP. Scrum limits by velocity, per time; Kanban limits by column in the workflow.
- Scrum discourages mid-sprint change: “We want to work in peace and quiet for a few weeks”. In Kanban, you just need to wait for a slot to become available.
- In Scrum, the board is reset between sprints. In Kanban the board has a long life. Scrum gives you closure and a feeling of success, but also some waste.
- Scrum prescribes one team per board, cross-functional. Kanban is more permissive of specialist teams.
- Scrum prescribes estimation and calculating velocity. In Kanban both are optional.
For more information, read the free PDF minibook.
My opinion: Well-structured and informative. I’d been curious about Kanban, wondering if it might be worth trying instead of Scrum (which we use now). After this presentation I have a good grip on the differences between the two and know that Scrum suits our needs better.

