“Kanban or scrum?” is the agile question every new lead asks, and the one most agile content answers badly. The honest answer is that they’re different shapes for different work — not better or worse, and rarely an either/or once you understand what each one actually delivers. This post is the practical version: what each really is, the four signals that tell you which one fits, and the hybrid most successful teams actually run.
The one-line difference
Scrum is a cadence. Kanban is a flow.
Scrum says: chunk work into 2-week iterations, plan at the start, demo at the end, retro the cycle. Cadence is the unit.
Kanban says: pull work continuously, limit how many things are in flight at once, optimise flow. Flow is the unit.
Both are agile (in the values sense). Both can produce excellent teams or dysfunctional ones. The choice is about what shape of work you’re doing, not whether your team is “advanced enough” for kanban.
What scrum actually is
Defined by the Scrum Guide. Three roles (Product Owner, Scrum Master, Developers), five events (sprint, planning, daily scrum, review, retrospective), three artefacts (product backlog, sprint backlog, increment).
The defining commitment: the sprint is the unit of value. You commit to a set of work for 2 weeks, you ship it as a coherent increment, you reflect, you start again.
That commitment makes sense when:
- You can predict 2 weeks of work without too much surprise
- The work is feature-shaped — discrete, designable, finishable
- Stakeholders want a regular cadence of demos
- The team benefits from forced reflection (retros) on a known interval
It breaks down when:
- Work is reactive — support tickets, ops escalations, urgent bugs
- Items vary wildly in size and you can’t usefully “commit” to a sprint
- The team’s job is to absorb whatever comes in, not to ship features
What kanban actually is
There’s no Kanban Guide equivalent — kanban is a method, not a framework. The core practices, drawn from the lean tradition, are:
- Visualise the work — a board with columns for each workflow state
- Limit work in progress (WIP) — explicit numerical limits per column
- Manage flow — measure how long work takes from start to finish (cycle time, lead time)
- Make policies explicit — clear rules for what “ready” or “done” means in each column
- Improve continuously — small experiments based on flow data
That’s it. No sprints, no required ceremonies, no required roles.
The defining commitment: the WIP limit is the unit of discipline. You don’t pull a new item until something is finished. Cycle time and throughput are the metrics that matter, not velocity.
That makes sense when:
- Work arrives unpredictably and you can’t plan a sprint around it
- Items are roughly similar in size or finish-time, so a cumulative-flow view is useful
- You want to optimise for time-to-shipped on individual items, not bundles
- The team is mature enough to self-regulate without a forced ceremony cadence
It breaks down when:
- The team has no internal pull to reflect and improve (retros are skipped, never reinstated)
- Work needs explicit cross-team synchronisation (e.g., releases that bundle multiple items)
- Stakeholders expect a regular cadence of “what shipped this period” updates
The four signals that pick for you
When teams ask “scrum or kanban?”, the answer falls out of four signals.
1. Predictability of incoming work
- Predictable, plannable in 2-week chunks → scrum
- Reactive, can’t be planned → kanban
Examples:
- Feature delivery on a product roadmap → scrum
- Customer support tier 2 → kanban
- Platform/SRE team → kanban (mostly)
- Mobile app team shipping monthly releases → scrum
2. Item size variance
- Items are roughly similar in size → either works
- Items vary wildly (1 day to 3 weeks) → scrum struggles, kanban handles it
Story points partially address size variance in scrum, but only if the team estimates well. If your team has 1-point and 13-point items in the same sprint, you’ll under- or over-commit constantly. Kanban with WIP limits doesn’t care about item size — it just limits how many are in flight.
3. Stakeholder cadence expectations
- Stakeholders want a “what’s coming this sprint” + “what shipped” rhythm → scrum
- Stakeholders want individual items shipped ASAP, no batching → kanban
A B2B SaaS product team selling on roadmap updates needs scrum (or scrum-shape). A growth-engineering team running A/B tests doesn’t — they want experiments shipped one at a time, fast.
4. Team appetite for ceremony
- Team values structured reflection time → scrum
- Team finds meetings draining and self-regulates well → kanban
Be honest here. Many teams say they want kanban because they hate ceremonies, then drift into never reflecting on their process and slowly degrading. Scrum’s forced retros catch that drift; kanban’s “manage flow” practice only works if someone actually does it.
The hybrid most teams actually run
Pure scrum and pure kanban are both rare. What works in practice for most product engineering teams:
Scrumban: scrum’s cadence + kanban’s flow discipline.
- Keep the 2-week sprint as a planning + retro cadence
- Drop the rigid sprint commitment — items can be added or removed mid-sprint with discussion
- Add WIP limits per column on the board
- Track both velocity (for forecasting) and cycle time (for flow health)
- Run a 30-min retro every sprint, not weekly
This works because most product teams have partially predictable work — features they want to ship, plus reactive bugs and small requests. Pure scrum forces the unpredictable into a sprint commit it doesn’t fit. Pure kanban abandons the planning cadence stakeholders need.
What this means in practice
If you’re a feature-delivery product team (frontend, backend, full-stack on a product roadmap): start with scrum, then drift into scrumban after 6 sprints.
If you’re a platform / SRE / ops team: start with kanban. Run a monthly retro instead of a sprint retro.
If you’re a support team or any team where >60% of work is reactive: kanban, no question.
If you’re a small startup engineering team (3–6 people): scrumban is usually right. The cadence helps, but full ceremony overhead doesn’t fit at small scale.
Tool implications
The underlying mistake teams make is choosing a tool before deciding the shape. Most “agile” tools are scrum-shaped (sprints, story points, burndown, velocity) and bolt on a kanban view as an afterthought. A few are kanban-shaped (continuous flow, WIP limits, cycle time) and bolt on sprints poorly.
If you’re scrum or scrumban, scrum-shaped tools are the right home. SprintFlint is built around the sprint cycle — automatic velocity, native retros, sprint-aware burndown — with a board view that supports WIP discipline if you want it.
If you’re pure kanban with no sprints, look at flow-first tools (Kanbanize, Plane in flow mode, Trello with Power-Ups). Scrum tools fit awkwardly.
TL;DR
- Scrum: cadence-first. Plan a sprint, ship it, retro, repeat. Right for predictable feature work.
- Kanban: flow-first. WIP limits, cycle time, no sprints. Right for reactive work or wildly variable items.
- The four signals: predictability, item-size variance, stakeholder cadence expectations, team appetite for ceremony.
- Most successful product teams run scrumban — sprint cadence with kanban-flavoured flow discipline.
- Pick the shape first, the tool second. Don’t let your tool make the choice for you.