Scrumban: how to combine Scrum and Kanban practices
Quick summary: what Scrumban is
Scrumban blends the two approaches: it preserves Scrum elements — planning, cadences, retrospectives, often Sprints themselves — and adds Kanban practices: board, WIP limits, pull system and flow metrics.
Work is pulled continuously within the cadence, planning can happen on demand when the queue runs low, and delivery is not tied to cycle boundaries.
It fits teams that want Scrum's structure with Kanban's flexibility — or that are evolving from one approach toward the other.
Before diving into reading:
Scrumban began as a transition technique and became a destination in its own right. This article explains what it keeps, what it adds and when it is the right fit.
Prerequisites are light: the basics of Scrum and Kanban.
1) What is Scrumban?
Scrumban is a hybrid approach that runs Kanban's flow system inside Scrum's structure. The team keeps a cadence of planning, review and retrospective — often keeping Sprints as time containers — while work itself moves by pull, under WIP limits, across a board that mirrors the real process.
There is no single official Scrumban; it is a family of configurations. What defines it is the deliberate mix: cadence and goals from Scrum, flow mechanics from Kanban.
2) What stays from Scrum
Most Scrumban teams preserve the cadence of planning and retrospectives, the Product Owner's ordered backlog and often the Sprint as a rhythm for goals and stakeholder reviews. Roles usually remain untouched.
This preserved skeleton is what distinguishes Scrumban from plain Kanban: the team still has structured moments to align direction, not just a flowing queue.
3) What comes from Kanban
From Kanban, Scrumban takes the full flow toolkit: a board with explicit columns and policies, WIP limits per stage, pull instead of push, blocker marking, and flow metrics — cycle time, throughput, aging WIP — as the primary measurement system.
Commitment shifts accordingly: instead of committing to a fixed batch at planning, the team commits to each item as it is pulled, keeping flexibility high.
4) Planning on demand
A signature Scrumban technique is trigger-based replenishment: rather than filling a whole Sprint at once, the team sets a threshold — say, three items left in Ready — and holds a short planning session whenever the trigger fires.
Planning effort spreads into small, frequent doses, and the backlog stays fresh: items are detailed just before execution, when knowledge is greatest. Teams that keep Sprints often use a lighter version: a minimal batch at Sprint start plus on-demand top-ups.
5) Metrics in Scrumban
Scrumban measures flow, not velocity. Cycle time distributions answer "how long does an item take?"; throughput answers "how much do we finish per week?"; aging WIP warns about items drifting. Forecasts come from these numbers rather than from story-point estimation, which many Scrumban teams drop entirely.
Reviews and retrospectives — kept from Scrum — become the forum where these metrics are inspected and turned into experiments.
6) When Scrumban fits best
Three situations call for it. Teams with mixed demand — roadmap work plus a constant stream of support and urgencies — get goals from the cadence and responsiveness from the flow. Maintenance-heavy teams get structure without pretending their work fits neat batches. And teams migrating between Scrum and Kanban get a stable intermediate configuration instead of a leap.
Signals that it will help: Sprints constantly broken by urgent items, planning sessions that feel wasteful because priorities shift, or a Kanban team missing alignment moments.
7) Getting started with Scrumban
From Scrum: keep everything, add the board and WIP limits (the step-by-step guide covers this), then gradually introduce on-demand replenishment and flow metrics. From Kanban: keep the board and limits, add a regular planning/review cadence and explicit goals.
Run the configuration for a few cycles, then let retrospectives tune the mix. Scrumban is not a compromise — it is a configuration space, and your team's best point in it emerges from evidence.
8) Conclusion
Scrumban keeps what Scrum does best — cadence, goals, alignment — and what Kanban does best — visibility, WIP control, flow. The result is structure without rigidity.
If your Sprints fight your reality, or your flow lacks direction, Scrumban is the pragmatic middle path. Start from where you are and evolve deliberately.