Scrumban: definition, principles and when to use it

Scrumban is an agile technique that combines Scrum and Kanban. It was created for teams that wanted to reduce batch size and adopt a pull-based approach, without abandoning the cadence and the ceremonies that give Scrum its rhythm. It is not a compromise for teams that cannot commit to Scrum: it is a deliberate answer to work whose arrival is not under the team’s control.

What it takes from each

From Scrum: the planning cadence, the retrospective and the shared goal. From Kanban: continuous flow, explicit work-in-progress limits and pulling work when capacity frees up rather than pushing it into a sprint. What it drops is the sprint commitment — the promise that a fixed set of items will be finished by a fixed date.

Work-in-progress limits do the heavy lifting

The single most consequential rule of Scrumban is the limit on items in progress per column. It feels restrictive and it is: a team that cannot start anything new must finish or unblock something first. That constraint is what converts a board full of half-done work into a steady flow, and it is the rule teams abandon first — usually right before their cycle time doubles.

Planning on demand instead of on schedule

Rather than a planning session every two weeks regardless of need, Scrumban triggers planning when the ready backlog drops below a threshold. The team replenishes it with the highest-priority items available at that moment. Priorities set two days ago beat priorities set two weeks ago, which is precisely the point for teams facing unpredictable demand.

Who it suits

Teams with a mix of planned work and unpredictable demand — maintenance, support, platform teams — often struggle with strict sprints. Scrumban lets them keep a rhythm without pretending that interruptions do not exist. Conversely, a team building a well-defined product increment with stable priorities usually gains more from the focus a sprint commitment provides.

Measuring it

Velocity means little without a sprint commitment. The relevant measures become cycle time — how long an item takes from start to done — and throughput, the number of items finished per week. Both are read from the board itself and are far harder to game than a story-point total.

Running it in practice

You need a board with limits, a backlog that is prioritised rather than committed, and a regular review point. FoxPlan supports both styles: kanban columns with custom labels per project, priority levels on cards and tasks, and the wider schedule for the work that still needs dates — so a Scrumban team feeds the same portfolio workload and budget as a predictive one.