A side-by-side decision guide. Both are Agile methods — Agile is the umbrella (see agile-manifesto.md); Scrum and Kanban are two ways to apply it. They are not opposites and not interchangeable.
For depth on each method: scrum.md / scrum-workflow.md and kanban.md / kanban-walkthrough.md.
One-Line Summary
- Scrum — iterate in fixed-length Sprints, commit to a Sprint Goal, ship at the end.
- Kanban — flow work continuously, limit work-in-progress, ship whenever something is ready.
Core Philosophy
| Scrum | Kanban | |
|---|---|---|
| Mental model | Time-boxed iterations | Continuous flow |
| Unit of work | The Sprint | The card on the board |
| Change posture | Adopt the framework as-is | Start with what you do now and evolve |
| Origin | Software product development (1990s) | Toyota lean manufacturing (1940s), adapted for knowledge work by David Anderson (~2007) |
Scrum says: "Pick a time-box, commit to a goal, inspect at the end." Kanban says: "Visualize the work, cap WIP, optimize flow."
Side-by-Side Comparison
| Dimension | Scrum | Kanban |
|---|---|---|
| Cadence | Fixed-length Sprints (1–4 weeks) | Continuous flow; no iterations |
| Roles | Product Owner, Scrum Master, Developers | None prescribed |
| Commitment | Commit to a Sprint Backlog + Sprint Goal | Pull work as capacity allows |
| Change mid-cycle | Avoided during a Sprint | Allowed any time |
| Estimation | Expected (story points) | Optional |
| Work limits | Limited by Sprint scope | Explicit WIP limits per column |
| Key metric | Velocity (points/Sprint) | Cycle time + throughput |
| Board | Cleared each Sprint | Persistent, always flowing |
| Meetings | 5 prescribed events | Optional cadences, run independently |
| Release model | At end of Sprint (or whenever DoD met) | Whenever work is ready; continuous delivery common |
| Planning event | Sprint Planning | Replenishment meeting (on demand) |
| Best for | Feature work with planning horizons | Support, ops, unpredictable or continuous work |
| Change philosophy | Revolutionary — adopt the framework | Evolutionary — improve incrementally |
When to Lean Scrum
- Building features with a planning horizon (roadmap, releases).
- Stakeholders need predictable demo/review checkpoints.
- The team benefits from rhythm and a forcing function for shipping.
- Requirements are uncertain but the work is project-shaped.
When to Lean Kanban
- Work arrives unpredictably (support, bug-fixing, ops, maintenance).
- Priorities shift faster than a Sprint boundary.
- You want to improve an existing process without reorganizing.
- Continuous delivery matters more than batched releases.
- The team is small or already mature and the ceremony overhead of Scrum outweighs its benefit.
Common Confusions
| Myth | Reality |
|---|---|
| "Kanban is more Agile than Scrum" | Both are Agile. Different tools for different shapes of work. |
| "Scrum without ceremonies is Kanban" | No — Kanban requires WIP limits and explicit flow management. Skipping Scrum events just gives you broken Scrum. |
| "Kanban has no planning" | It has just-in-time planning (replenishment meeting) instead of batched Sprint Planning. |
| "Scrum prohibits mid-Sprint changes" | The Sprint Goal is fixed; the Sprint Backlog can flex as the team learns. |
| "Kanban means no estimates" | Estimation is optional, not forbidden. Many teams still size cards for forecasting. |
| "We're doing Scrum because we have standups" | Standups don't define Scrum. Sprint Goal, Sprint Backlog, Increment, and the full event set do. |
Scrumban — The Hybrid
Many teams blend the two. Scrumban keeps Scrum's structure (some cadence, accountabilities, Retros) but adds Kanban's WIP limits and pull-based flow, often dropping rigid Sprint commitments. Common landing spots:
- Scrum teams that adopt WIP limits and a persistent board.
- Teams that keep Retrospectives but replenish on demand instead of full Sprint Planning.
- A pragmatic middle ground when pure Scrum feels too rigid but pure Kanban feels too loose.
It is not a separate method — it's a labelled set of compromises. Use it intentionally, not as a way to avoid choosing.
Quick Decision Guide
Is the work mostly feature delivery on a roadmap?
└─ YES → Sprint Goal helps. Lean SCRUM.
└─ NO → continue ↓
Does work arrive unpredictably (tickets, incidents, requests)?
└─ YES → fixed Sprints break down. Lean KANBAN.
└─ NO → continue ↓
Do stakeholders need fixed demo checkpoints?
└─ YES → SCRUM provides the rhythm.
└─ NO → continue ↓
Is the team already mature and self-managing?
└─ YES → KANBAN's lighter overhead is enough.
└─ NO → SCRUM's structure helps the team learn the practice.
If still torn: try Scrumban — Scrum cadence + WIP limits.
TL;DR
Use Scrum when you can commit to a Sprint Goal and the team benefits from rhythm. Use Kanban when work is interrupt-driven and continuous delivery matters more than batched releases. Use Scrumban when neither extreme fits.