Scrum vs. Kanban

---

The Two Bets

Scrum and Kanban are not opposites, but they make different bets about what produces team focus and effective flow. Scrum bets on time-boxed sprints, sprint goals, and the social contract of a commitment everyone can see. Kanban bets on visible flow, explicit work-in-progress limits, and the discipline of pulling work only when capacity exists.¹

Both work. Both fail. The choice between them is less about right-and-wrong than about which kind of discipline a team can sustain and which kind of work they actually do.

What Scrum Optimizes For

Scrum's design assumptions:

• Work can be planned in bounded chunks (typically two weeks).
• The team benefits from a regular rhythm of commitment, review, and reflection.
• Stakeholders need a predictable cadence for feedback.
• The sprint goal — a single overarching purpose for the sprint — produces alignment and focus.
• Mid-sprint scope changes are disruptive and should be deferred to the next sprint.

When these assumptions hold, Scrum's cadence produces reliable forecasts, sharp focus, and a natural rhythm of inspection and adaptation. The sprint goal in particular is an underrated mechanism — a team that always knows why this sprint matters tends to make better tactical decisions than one that doesn't.

What Kanban Optimizes For

Kanban's design assumptions:

• Work arrives unpredictably and in varied sizes.
• The team's primary lever is reducing cycle time, not increasing batch size.
• Limiting work-in-progress produces more throughput than maximizing capacity.
• Continuous flow is more honest than artificial batching.
• Forecasting from throughput history beats forecasting from planned commitments.

When these assumptions hold, Kanban produces shorter lead times, fewer half-finished items, and a continuous learning loop driven by the team's own metrics. It is particularly powerful for operations-heavy or interrupt-driven teams where Scrum's planning ritual would produce mostly waste.

Where Scrum Breaks

• Highly unpredictable work. When most of the team's work is reactive — incidents, support, urgent customer requests — Scrum's sprint commitment becomes a fiction maintained for ceremony.
• Mid-sprint disruption is normal. If the team routinely abandons sprint plans for emerging priorities, Scrum's discipline is being used theatrically.
• The sprint goal cannot be articulated. If the team can only say "we'll work on whatever is at the top of the backlog," Scrum is being run with the form but not the substance.
• Stakeholder cadence misaligns. If review feedback arrives between sprints rather than at the review, the cadence isn't serving its purpose.

Where Kanban Breaks

• No real WIP limits. Kanban without enforced limits is just a board with statuses. The limits are the entire mechanism.
• No throughput tracking. Without measuring cycle time and throughput, Kanban loses its forecasting and learning power.
• No regular reflection. Without explicit retrospectives or operations reviews, the continuous-flow model becomes an excuse to never stop and improve.
• Drift to feature factory. Without sprint-style goals, teams can ship continuously without ever asking "is this making a difference?"

The Hybrid: Scrumban

Most teams that adopt one of these methods rigorously end up borrowing from the other. Scrumban — the pragmatic hybrid coined by Corey Ladas — keeps Scrum's events and roles (sprint planning, review, retro, PO, SM) but adds Kanban's WIP limits and cycle-time metrics.² The result is a team that has both the focus of cadence and the discipline of flow.

For most product teams, Scrumban is more honest than either pure form. The teams that succeed with pure Scrum tend to have unusually predictable work. The teams that succeed with pure Kanban tend to have unusually mature flow discipline. Most teams have neither, and hybrid practices serve them better.

The Underlying Question

This debate hides a more useful question: where does the team most need its discipline imposed?

• If the team needs a cadence to focus — Scrum.
• If the team needs a limit on simultaneous work — Kanban.
• If the team needs both — Scrumban.
• If the team needs neither, what they actually need is leadership clarity, not a process change.

The debate is sometimes used as a proxy for the deeper question of "is our process working for us or are we working for it?" That question has no answer in the methodology. It has an answer in what the team actually delivers and how they feel doing it.

Coaching Tips

Measure mid-sprint disruption.

If a Scrum team routinely abandons sprint plans, the cadence isn't serving them. Either remove the disruption sources or switch to Kanban.

Check that WIP limits are enforced.

A Kanban board without enforced limits is just a status board. The limits are the active ingredient.

Don't switch methods to fix culture.

A team that ignores Scrum will also ignore Kanban. Methodology change rarely fixes a discipline problem.

Start with the smaller change.

Add WIP limits to a Scrum team before switching to Kanban. Add a sprint goal to a Kanban team before switching to Scrum. The smaller change often produces the desired effect without the disruption.

Watch the sprint goal.

If a Scrum team can't articulate a sprint goal beyond "complete these tickets," Scrum is being run as theatre. Either fix the goal-setting or admit the team is doing Kanban with extra steps.

Embrace Scrumban without apology.

Most teams converge on a hybrid. Pretending to be one or the other purely is performance. The hybrid is honest.

Summary

Scrum vs. Kanban is one of the most-debated and least-useful arguments in agile. Both methods work in the conditions they were designed for, both fail when forced onto conditions they were not. The interesting question is not which method is better but what each method is actually doing for the team — and whether the team needs that specific discipline more than it needs the alternative. Most healthy teams discover the answer is "some of both," and Scrumban is what they end up calling it.

Back to The Great Agile Debates