Scrumban
Scrumban is a hybrid agile approach that keeps Scrum’s team and improvement loop while adopting Kanban’s continuous-flow mechanics: work-in-progress limits, a pull system, and flow metrics instead of a rigid all-or-nothing sprint commitment. In short, you organize like Scrum but flow work like Kanban.
It began as a way to move a Scrum team toward Kanban gradually, and became a standalone approach for teams that want Scrum’s team and retrospective habit without its fixed batch of committed sprint work. The useful question is not “is it Scrum or Kanban” but which parts of each it combines, so this article spells that out.
Also known as
Scrum-ban · “Scrum with Kanban” · the Scrum/Kanban hybrid
Don't confuse with
- Scrumban vs “Scrum with a board.” Putting a Kanban board next to your Scrum sprint does not make it Scrumban. Scrumban specifically adds WIP limits and pull-based flow and relaxes the sprint commitment. A board alone is just a board (the same confusion Kanban warns about).
- Scrumban vs running Scrum and Kanban side by side. It is a single integrated method, not two processes bolted together.
What it keeps from Scrum
- The team, though Scrumban is looser about prescribed roles than Scrum.
- Retrospectives and the continuous-improvement loop.
- A planning activity, but triggered on demand rather than on a fixed sprint cadence (see below).
What it takes from Kanban
- WIP limits: a cap on how many items are in progress at once, the heart of the flow.
- A pull system: you pull the next item when you have capacity, not when a sprint boundary says so.
- Continuous flow: work moves item by item across the board rather than being frozen into a fixed sprint batch.
- Flow metrics: cycle time and throughput, rather than a sprint burndown, to measure and forecast.
What it drops or relaxes
- The strict sprint commitment. Work isn’t locked into a fixed sprint scope; the team pulls as capacity frees, so mid-cycle change is fine.
- Story-point estimation, often. Many Scrumban teams skip pointing and forecast from throughput instead (Ladas argued you only need the average item size, not a per-item estimate). This is common, not universal, some teams keep estimating. It ties to the size-blind-throughput trade-off noted in Kanban: throughput forecasting works when items are kept small and similar.
Planning on demand
The signature mechanic is planning on demand: instead of planning at every fixed sprint boundary, the team triggers a planning session when its queue of ready work drops below a threshold. Ladas called this threshold the order point, borrowed from lean inventory (reorder stock when it runs low). Planning then happens just in time and just enough, keeping a small buffer of ready items without over-committing a whole sprint up front.
In plain English
Keep Scrum’s team and its regular retrospective, but stop cramming work into fixed sprints. Put a limit on how many things are in progress, pull the next item when you finish one, and plan more work only when you’re about to run out.
When to reach for it
- A Scrum team drifting toward flow: frequent interruptions, support work, or changing priorities make the fixed sprint commitment feel like a straitjacket.
- Maintenance and operations work with unpredictable arrival, where Kanban’s flow fits but you still want Scrum’s team and retro discipline.
- As a transition step from Scrum to Kanban without a disruptive big-bang switch.
Origin
Scrumban was introduced by Corey Ladas in his 2008–2009 writing (collected in Scrumban: Essays on Kanban Systems for Lean Software Development). He framed it first as a transition from Scrum to Kanban, applying lean and pull-system ideas to Scrum’s iterations. There is no single official Scrumban specification the way there is a Scrum Guide, so practice varies between teams.
See also
- Scrum · Kanban: the two approaches it blends
- Estimation: story points vs throughput, the forecasting choice Scrumban usually makes
- Agile software development: the family all three belong to
- Software development process: where hybrids sit among the approaches
References
- C. Ladas, Scrumban: Essays on Kanban Systems for Lean Software Development, Modus Cooperandi Press (2009). The book that introduced Scrumban (from 2008 essays). https://books.google.com/books/about/Scrumban_Essays_on_Kanban_Systems_for_Le.html?id=SQFdAgAAQBAJ
- C. Ladas, “Scrumban” (original 2008 essay), Agile Alliance. The primary source for the order-point mechanic; note Ladas’s own caveat that it “was never intended to be a defined, prescriptive process.” https://agilealliance.org/scrumban/
- A. Reddy, The Scrumban [R]Evolution: Getting the Most Out of Agile, Scrum, and Lean Kanban, Addison-Wesley Professional (2015). https://www.informit.com/store/scrumban-revolution-getting-the-most-out-of-agile-scrum-9780134086217