Scrum vs Kanban vs Scrumban: What Scrumban Is

The Answer

Scrumban is a hybrid that keeps scrum’s planning rhythm and adds kanban’s WIP limits and flow metrics. In the usual scrum vs kanban vs scrumban comparison, scrum gives you fixed sprints with defined roles, kanban gives you continuous flow with capped work in progress, and scrumban sits between them: the team keeps a recurring planning cadence and a retrospective, then drops the sprint commitment so work flows across the boundary and caps how much sits in progress at once. It usually arrives as a destination rather than a starting point, adopted by scrum teams whose sprint commitments kept breaking and who were not ready to abandon the structure entirely.

What Is Scrumban?

Scrumban is the practice of running a kanban system inside a scrum-shaped calendar. Corey Ladas coined the term in his 2008 book Scrumban: Essays on Kanban Systems for Lean Software Development, and he framed it as a transition path: a way for a scrum team to adopt kanban gradually without a disruptive switch.

That framing still describes most real adoptions. Almost nobody starts a new team on scrumban. They start on scrum, discover that the sprint commitment keeps getting renegotiated, and reach for something that keeps the useful parts.

What it takes from each side is fairly consistent:

• From scrum: a recurring planning cadence, the retrospective, often the daily standup, and sometimes the roles.
• From kanban: WIP limits per column, a persistent board, pull-based work selection, and flow metrics like cycle time and throughput.
• Dropped: the sprint commitment, which is the mechanic that made a sprint a sprint.

Scrum vs Kanban vs Scrumban Compared

	Scrum	Kanban	Scrumban
Cadence	Fixed sprints, one month or less	Continuous flow	Planning cadence without a scope commitment
Board	Cleared each sprint	Persistent	Persistent
Work selection	Batch, at sprint planning	Pull one item when a slot opens	Pull, topped up on a cadence
Limiting work	Sprint scope	WIP limits per column	WIP limits per column
Roles	Product owner, scrum master, developers	None required	Usually kept, often loosened
Core metrics	Velocity, burndown	Cycle time, throughput, WIP	Flow metrics, sometimes both
Change mid-cycle	Discouraged	Expected	Absorbed, queue reprioritised
Retrospective	Required	Optional, widely used	Kept

The row that matters is work selection. Everything else follows from whether the team is promising a batch or pulling items.

The Three Versions Teams Actually Run

“Scrumban” covers at least three different setups, and knowing which one you mean saves a lot of confused conversations.

Scrum plus WIP limits. The lightest version. Sprints, roles and events all stay, and the team adds a cap to the middle columns. Nothing in the Scrum Guide forbids this, and it fixes the common failure of a team pulling all fifteen sprint items into “in progress” on day one. If you only try one thing from this article, try this.

Sprint as a planning rhythm. The sprint boundary survives as a calendar event but stops scoping the work. The team meets fortnightly to reprioritise, the board keeps running through the boundary, and unfinished items simply stay where they are. This is the version most people mean by scrumban.

Kanban with scrum ceremonies. Continuous flow, WIP limits, flow metrics, and the retrospective and standup retained because they are useful. At this point you are running kanban and keeping two meetings, which is a perfectly good place to end up. Calling it scrumban is generous.

When Does Scrumban Help?

Scrumban helps when a team needs kanban’s flow but would lose something real by dropping scrum’s structure overnight. Four situations where I would reach for it:

1. Sprint commitments keep breaking. The team is honest about it, morale is dropping, and nobody wants to formally abandon the framework. Scrumban gives an off-ramp that does not read as failure.
2. The work is genuinely mixed. Half planned feature work, half incoming support. A sprint handles the first badly once the second interrupts it.
3. Stakeholders are attached to the cadence. They like the fortnightly demo. Keeping the rhythm while loosening the commitment costs nothing and buys goodwill.
4. The team is moving to kanban and wants a staged transition. Which is exactly what Ladas designed it for.

Where it does not help: a team that has never had a WIP limit and is hoping scrumban will fix a prioritisation problem. It will not. A board with no cap and no clear owner of the queue behaves the same whatever you call it.

Is Scrumban Just Scrum With Extra Steps?

Sometimes, and it is worth being honest about when. If a team keeps sprint planning, keeps the commitment, keeps every ceremony, and adds a WIP limit nobody enforces, the label has changed and the behaviour has not. I have seen that adoption more than once, and it usually surfaces in the retrospective about two months in, when someone points out that nothing about the week feels different.

The test is mechanical. Ask two questions. Does an unfinished item at the end of the cycle stay on the board, or go back to a backlog? And does the team stop starting new work when a column hits its cap? Two yeses mean the system changed. Two noes mean you renamed scrum.

How Do You Move From Scrum to Scrumban?

Take it in three steps and give each one a couple of weeks before adding the next.

1. Cap the columns. Put a WIP limit on wherever work piles up, usually the doing or review column. Start with the number of people who pull from it plus one. WIP limits covers how to pick and tune the number.
2. Stop clearing the board. Let unfinished items carry across the sprint boundary. This is the change that actually converts the system, and it is smaller than it sounds.
3. Swap the commitment for replenishment. Keep meeting on the same schedule, but refill the queue rather than promising a batch. The meeting usually gets shorter.

Keep the retrospective throughout. Add flow metrics once the board has a few weeks of history, since cycle time is what will eventually replace velocity when someone asks for a date. If you decide to keep the sprint after all, kanban vs sprint covers what the time box is genuinely buying you.

FAQ

Is scrumban an official framework?

No. There is no scrumban guide with the standing of the Scrum Guide, no certification body that owns the definition, and no canonical rule set. It is a widely used practice with a name, which is why implementations vary so much between teams.

What is the difference between kanban and scrumban?

Scrumban keeps a recurring planning cadence and usually scrum’s roles and retrospective, while kanban prescribes none of that. Both cap work in progress and run a persistent board, so the day-to-day mechanics can look nearly identical.

Does scrumban use story points?

Some teams keep them and many drop them. Once a board has cycle-time history, forecasting from that history tends to answer the same questions with less ceremony. Teams that keep estimating often reduce it to rough size buckets.

Do you need a scrum master for scrumban?

Not formally, since nothing requires the role. Teams coming from scrum usually keep the person, because the coaching and impediment-clearing work does not disappear when the framework label changes.