Sunday, May 9, 2010

Scrum and Kanban

Kanban and Scrum - making the most of bothHenrik Kniberg and Mattias Skarin compare Scrum and Kanban in their book “Kanban and Scrum – Making the Most of Both”.

Scrum consists of
Small cross functional self-organizing teams
Time boxes for the Sprint, Release Planning, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective
Artifacts: Product Backlog, Sprint Backlog, Release Burndown and Spring Burndown.

Scrum requires small cross functional self-organizing teams. Each Scrum team is composed of a product owner, a ScrumMaster, and the team. The Product Owner maintains and prioritizes the product backlog in a way that maximizes value of the work performed by the team. The team works in short fixed length iterations and consists of developers with all the necessary skills to deliver the committed to features by the end of the iteration. The Sprint starts with a Sprint planning meeting to produce the Sprint backlog from high priority feature in the product backlog. This is followed with daily work on small concrete items from the Sprint backlog, and ends with a Sprint Review to demo the deliverables as well as a Sprint retrospective to review the process. Everyday the team also has a Daily Scrum meeting to ensure progress towards the Sprint goal and update the Sprint Burndown chart. A release planning meeting is held before the start of each release to estimate and prioritize features to be included in the next release. After each Sprint, the Release Burndown chart is update to show and track release progress. Throughout, the ScrumMaster ensures that the process is understood and followed and removes any impediments to the team’s progress.

Kanban is based on limits on Work in Progress. It uses a visual control mechanism (Kanban Board) to track work as it flows through the various stages of the value stream. The board tracks states like to-do, in development, in testing, completed, etc. Each state has a limit on the number of items that it can hold. Work is split into pieces and progresses through the workflow however no items can proceed unless there is enough capacity in the next state. Lead time or cycle time is constantly measured and optimized to make it as small and as predictable as possible. Kanban does not prescribe artifacts and team composition like Scrum does. Kanban leaves everything open. The only constraints are visualizing the workflow and limiting WIP.

Henrik summarizes the similarities and differences as follows:



releasable software early and often

“potentially shippable” at end of each Sprint

Scheduled or on demand

to drive process improvement

Product Backlog, Sprint Backlog, retrospectives

Kanban Board

Pull Scheduling

Items are pulled from product backlog at beginning of each Sprint

Items pulled when a slot becomes available


Timeboxed iteration prescribed for Sprint, Release
Planning, Sprint Planning, Daily Scrum, Sprint Review, and Sprint

Timeboxed iterations optional. Process can
be event driven instead of timeboxed. Each meeting
can occur at different


Sprint Backlog/Scrum board is reset after each Sprint

Kanban board is persistent

Item Size

Items must be broken down to fit into 1 sprint

No sizing requirements


Estimation prescribed

Estimation optional


Prescribes a prioritized backlog

Prioritization optional


Team commits to specific work in an iteration

Commitment optional.

Process Improvement Metric

Based on Velocity

Based on Lead time


Product Backlog,
Sprint Backlog, Release Burndown and Spring Burndown prescribed

Kanban Board

WIP Limits

Indirectly based on what can
fit into a Sprint

Directly based on limits set for each stage in the workflow

Responding to change

Cannot add items to an ongoing iteration

Can add new items whenever there is capacity

Team composition

Cross-functional teams prescribed

Silos and specialist teams allowed


Sprint backlog is owned by one specific team

A Kanban board may be shared by multiple


3 roles: Product Owner, Team, ScrumMaster

No roles prescribed

Scrum and XP from the Trenches (Enterprise Software Development)Henrik and Mattias recommend you not limit yourself to one tool. Mix and match as needed based on your organization's circumstances.