Henrik 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:
Scrum | Kanban | |
Delivering releasable software early and often | “potentially shippable” at end of each Sprint | Scheduled or on demand |
Transparency 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 |
Iterations | Timeboxed iteration prescribed for Sprint, Release Planning, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective | Timeboxed iterations optional. Process can be event driven instead of timeboxed. Each meeting can occur at different times. |
Resets | 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 | Estimation prescribed | Estimation optional |
Prioritization | Prescribes a prioritized backlog | Prioritization optional |
Commitments | Team commits to specific work in an iteration | Commitment optional. |
Process Improvement Metric | Based on Velocity | Based on Lead time |
Artifacts | 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 |
Ownership | Sprint backlog is owned by one specific team | A Kanban board may be shared by multiple teams |
Roles | 3 roles: Product Owner, Team, ScrumMaster | No roles prescribed |
Henrik and Mattias recommend you not limit yourself to one tool. Mix and match as needed based on your organization's circumstances.
