Scrum vs Kanban
Scrum is an Agile framework that runs work in fixed-length sprints (usually 1–3 weeks), with defined roles and ceremonies. Kanban is a continuous-flow method: no sprints, no fixed cadence, just visualised work, limits on how much can be in progress at once, and continuous improvement. Both are popular; they suit different kinds of work and different team cultures.
Last reviewed on 2026-04-27.
Quick Comparison
| Aspect | Scrum | Kanban |
|---|---|---|
| Cadence | Fixed-length sprints (1–3 weeks) | Continuous flow; no fixed iterations |
| Roles | Product Owner, Scrum Master, Development Team | No prescribed roles |
| Ceremonies | Planning, Daily Stand-up, Review, Retrospective | Optional; many teams keep stand-ups and retros |
| Work limits | Sprint scope is set at planning | Work-in-progress (WIP) limits per column |
| Change mid-cycle | Discouraged within a sprint | Always allowed — flow adjusts continuously |
| Metrics | Velocity (points per sprint) | Cycle time, throughput, WIP |
| Best fit | Project-shaped product work with discrete deliverables | Steady-state work, support, ops, mixed-priority queues |
Key Differences
1. Cadence
Scrum's heartbeat is the sprint. Work is planned, executed, and reviewed in a fixed period. Each sprint produces a "potentially shippable" increment.
Kanban has no heartbeat. Items flow through the board as capacity allows. There's no day-zero or day-N — every day is the same.
2. Roles and ceremonies
Scrum defines roles (Product Owner, Scrum Master, Developers) and ceremonies (Sprint Planning, Daily Stand-up, Sprint Review, Sprint Retrospective). The structure is part of the framework.
Kanban prescribes no roles or ceremonies. Many teams keep useful ones (a daily stand-up, periodic retros), but the method itself is silent on who does what.
3. Limiting work
Scrum limits work per sprint. The team commits to a sprint backlog and (in principle) doesn't add new items mid-sprint.
Kanban limits work-in-progress per column. Only N items can be in "in progress" at once; only M items can be in "review." That forces flow rather than queue depth.
4. Change tolerance
Scrum resists changes within a sprint to give the team a stable plan to deliver against. Change happens at sprint boundaries.
Kanban tolerates change always. Need to push something urgent? Pull it onto the board (within WIP limits) and an existing card may need to be parked.
5. Metrics
Scrum's default metric is velocity — work delivered per sprint. Useful for forecasting; sometimes misused as a productivity score.
Kanban's metrics are flow-based: cycle time, throughput, work-in-progress. They're harder to game and more directly aligned with delivery speed.
6. Where each fits
Scrum works well for project-shaped product work — building features, hitting milestones, pacing toward releases.
Kanban works well for ops, support, infrastructure, and any team where work arrives unpredictably and the priority is steady throughput more than predictable batches.
When to Choose Each
Choose Scrum if:
- Building a product with milestone-paced releases.
- New teams that benefit from the structure (roles, ceremonies, time-boxed planning).
- Stakeholders who need predictable demos and review windows.
- Cross-functional product teams shipping increments together.
Choose Kanban if:
- Support, on-call, ops, and SRE teams where work is interrupt-driven.
- Teams with mixed work — features, bugs, urgent fixes — and shifting priority.
- Mature teams that don't need ceremony imposed from outside.
- Anywhere work-in-progress and cycle time matter more than fixed cadence.
Worked example
A product team shipping a quarterly roadmap runs Scrum: two-week sprints, planning meetings, sprint reviews stakeholders attend. Their colleagues on the platform team handle whatever the company throws at them — production incidents, internal requests, infra upgrades. They run Kanban: a board with WIP limits, daily stand-up, no sprints. Same company, two methods, both right for their work.
Common Mistakes
- "Kanban means no process." It has structure: visualised work, WIP limits, explicit policies, continuous improvement. The structure just isn't time-boxed.
- "Scrum is more rigorous than Kanban." Different rigour. Scrum is rigorous about ceremony and cadence; Kanban is rigorous about flow and limits.
- "Mixing them is forbidden." "Scrumban" is a real and useful hybrid — Scrum cadence with Kanban-style WIP limits.
- "Velocity is the metric." Velocity is one metric, useful for forecasting; throughput, cycle time, and quality matter at least as much.