Comparing Kanban To Scrum

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) http://www.crisp.se/ScrumAndXpFromTheTrenches.html

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: http://availagility.wordpress.com/2008/10/28/kanban-flow-and-cadence/

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:

Similarities

• 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)

Differences

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.