Scrumban

Scrumban on one screen

Scrumban has no guide and no owning body, so the clearest definition is what it does to each part of Scrum. Here is every element of the Scrum Guide and what becomes of it — kept, changed or dropped — with the rule a team writes down in its place. Read it as the usual shape rather than a standard: teams vary, and the sections below say where.

In one picture: a Kanban board with limits, a threshold under the Ready queue that calls planning when the queue runs low, and Scrum’s cadence running underneath on a fixed rhythm.

Why it exists: the sprint that interrupts break

Here is the situation Scrumban solves. A team runs Scrum properly. Then production incidents start taking a third of its capacity, and it misses the Sprint GoalSprint Goalwhy this sprint existsOne sentence, agreed at Sprint Planning, saying what will be different at the end of the sprint and why it is worth doing. It is what lets a team drop or swap individual items mid-sprint without failing — a sprint judged only by its list of tickets has a quota, not a goal.Full article →All terms three sprints in a row. Nobody did anything wrong — the goal was simply never realistic given the interruptions.

The arithmetic is short. A team that finishes about thirty items a fortnight plans a goal around thirty. If a third of every fortnight goes to incidents and requests that cannot wait, twenty are left for the goal — and the team does not know in advance which third of the fortnight it will lose. Planning twenty only works if the interrupts arrive at the same rate every sprint, and they rarely do.

What usually happens next is quiet decay. The team keeps holding sprint planning, keeps calling the fortnight a sprint, and everyone silently stops taking the goal seriously. The ceremonies remain and the meaning drains out of them. These are the signals that the shape of the work, not the team, is the problem:

Two meanings of the word

The word has drifted, and the drift explains most arguments about it. Corey Ladas, a former Microsoft development manager, coined it in a 2008 essay and expanded it into a 2009 book, "Scrumban: Essays on Kanban Systems for Lean Software Development". His Scrumban was a path, not a place: start from Scrum, change one practice at a time toward continuous flow, let the process stabilise, measure, and repeat.

In later remarks he put it bluntly. Scrumban, he wrote, is a deployment strategy for continuous delivery; it is not an approach to doing Kanban and not a set of practices. A team that reaches continuous delivery has, by his definition, left Scrumban behind.

Most teams that use the word today mean something else: a stable hybrid, reached by stopping partway along that path with the intention of staying. Two more texts have since drawn the line in other places. Ajay Reddy’s "The Scrumban [R]Evolution" (2015) treats Scrumban as the Kanban Method applied to a team that starts from Scrum. Scrum.org’s "Kanban Guide for Scrum Teams", written with Daniel Vacanti in February 2018 and revised in 2021, goes the other way: it adds WIP limits, flow measures and a service level expectationSLEService Level Expectation — how long an item should take, with a probabilityA forecast a Kanban team publishes from its own history: a duration and a probability, such as "85 percent of items finish within 11 days of starting". It describes what the system has been doing rather than promising what it will do, so it changes whenever the system does.Full article →All terms to Scrum while keeping the SprintSprinta fixed-length work cycleA fixed period, usually one to four weeks, at the end of which there is something finished enough to show. The length is fixed and the scope moves — a sprint that is extended to fit the work has given up the only thing it was for.Full article →All terms and the Sprint Goal intact. That is Scrum with Kanban, and deliberately not Scrumban.

The three numbers you must choose

Setting up Scrumban is mostly a matter of picking three numbers. Get these right and the rest follows; leave them vague and you have a board with no rules.

1. The WIP limit

Set it per column, not per person. A per-person limit lets everyone start something and still produces a board full of unfinished work.

A workable starting point is one and a half items per developer in the "in progress" column. For a team of four that is six. Then lower it over a few weeks until people occasionally hit it. The Kanban page has the arithmetic of why a lower number finishes work sooner.

2. The order point

This is the number that replaces the start of a sprint: when the Ready queue holds fewer than N items, planning is called. Ladas borrowed the idea, and its name, from inventory control, where a warehouse reorders stock when a shelf falls to a set level rather than on a set day. The level is chosen so that new stock arrives just before the shelf empties.

For a board the same arithmetic reads: order point equals items pulled per day, times the days it takes to hold planning and refine the new items, plus a small safety margin for a slow week.

3. The retained cadence

Decide which Scrum meetings stay, and put them in the calendar as recurring events. The retrospective is mandatory. The daily meeting and a review every two weeks are usually worth keeping. Planning becomes on demand, called by the order point.

Planned work and interrupts on one board

The situation Scrumban is reached for usually has two kinds of work fighting over one team: work that can be planned and work that cannot wait. Kanban’s answer, and the one most Scrumban teams adopt, is capacity allocation. The WIP limit is split between kinds of work in advance, and each kind is drawn as its own horizontal lane with its own limit.

The numbers are the policy, and they are argued once, calmly, at a retrospective, rather than for each request under pressure. If the unplanned lane is always full while the planned lane starves, the split was wrong: change it, and the change shows up in the measures rather than in anyone’s mood. The improvement lane’s limit of one is the most important number on the board. Without a guaranteed slot, work with no deadline loses to work with one every single time, and the system slowly decays.

Planning beyond the next fortnight

One question comes up as soon as the sprint goal disappears: how do you plan anything beyond the next two weeks? Ladas’s book answers it with bucket planning, or the three-bucket system. Work sits in one of three buckets, and items move forward one bucket at a time as they become clearer.

• 1-year bucket

  Strategic direction. Vague statements of intent, no detail, no estimates. Reviewed a few times a year.

• 6-month bucket

  Things the business has decided it wants. Shaped enough to discuss, not yet broken down.

• 3-month bucket

  Ready to be refined and pulled onto the board. This is where the planning called by the order point draws from.

The point of the buckets is that detail is added only when an item moves forward. Nothing in the one-year bucket is estimated, because estimating something you may never build is the clearest form of wasted planning.

Two more mechanisms in the standard description of Scrumban are for the end of a fixed-date project, where a pull system meets a deadline — and they are the part most summaries leave out. A feature freeze means that as the date approaches, nothing new enters the board and only items already in progress continue. Triage follows straight after the freeze: someone with the authority to do it decides which items in progress will be finished and which will be stopped and taken off the board. Both are easy to describe and hard to do, and both exist because a pull system on its own does not know that a date is coming.

Side by side with its parents, and one measured switch

Siemens Health Services, 2012

The best-documented switch of this kind did not call itself Scrumban, but by this page’s definition that is what it was. Siemens Health Services had run Scrum since 2005. By 2012 its Soarian Financials programme — about fifteen Scrum teams in Malvern, Pennsylvania, in Brooklyn and in Kolkata — found that story pointsstory pointsrelative size, not hoursA unit for estimating the relative size of backlog items — an 8 is roughly twice a 5 — deliberately not tied to hours. They are useful for one team’s planning and nothing else: turned into a target or compared across teams, they inflate instead of measuring.Full article →All terms and velocity gave it no usable forecast at the scale of a release.

In May 2012 the teams dropped sprint planning, time-boxed sprints, story points and velocity, and moved to continuous pull with WIP limits, measuring cycle time and throughput on cumulative flow diagramscumulative flow diagramstacked bands of work by stage over timeA chart that plots, for every day, how many items have entered each stage of a workflow so far, drawn as stacked bands. The vertical gap between two lines is the work in progress between them and the horizontal gap roughly how long an item spends there, so a band that keeps widening marks a bottleneck.Full article →All terms and scatterplots. They kept their engineering practices, their monthly retrospectives and their team and programme reviews. Bennet Vallet of Siemens reported the results in 2014:

Where it degrades

Scrumban is arrived at far more often than it is chosen. That is fine — but the arrival should be a decision, announced to stakeholders, rather than a drift nobody names. StakeholdersStakeholderanyone the outcome affectsAnyone whose work or results are affected by what is being built, whether or not they can decide anything about it. The distinction that matters in practice is between those who are consulted and those who can say no.All terms who were promised a sprint goal need to know that the commitment has changed shape. What they get instead is a forecast from measured cycle time, which is often more honest — but only if someone tells them the swap happened.

The honest limit: Scrumban fixes a mismatch between the shape of the work and the shape of the process. It does not reduce the interrupts; it only stops them breaking a promise they were always going to break. If a third of the team’s time goes to incidents, the useful question is why — and that question belongs to the retrospective and to whoever owns the system producing the incidents, not to the board.

• Dropping the sprint commitment without adding a WIP limit — that is not Scrumban, that is an unbounded queue.
• Keeping the sprint name and ceremonies while quietly ignoring the goal, which hides the change from stakeholders.
• No order point, so planning happens when someone remembers and the queue runs dry.
• The retrospective lapsing because no sprint boundary forces it into the calendar.
• VelocityVelocityhow much fits in a sprintHow much a team actually completes in a sprint, averaged over several. It is a planning aid for that one team and nothing else — comparing the velocity of two teams, or setting it as a target, reliably produces inflated estimates rather than more work.Full article →All terms still reported upward alongside cycle time, so the team is judged on a number its process no longer produces.
• An expediteexpeditethe class of work for emergenciesThe Kanban class of service for genuine emergencies: an expedite item jumps the queue and ignores the WIP limit. It only works with a strict cap, usually one at a time — without one, every request someone senior cares about becomes an emergency.Full article →All terms lane with no limit, which turns the whole board back into an interrupt queue.
• No improvement lane, so technical debt waits for a sprint that no longer exists.
• Sprints announced on the calendar while items are swapped on the board every day — Scrum in name, no process in fact.
• Adopted to escape the discipline of Scrum rather than to fit the shape of the work.

When to use it

Related pages

• ManagementScrumScrum is a framework in which a team of ten or fewer ships a usable increment in fixed cycles of a month or less, called sprints, and adapts at five set events. It defines three accountabilities, three artefacts and those five events, and deliberately nothing about engineering. The page opens with the whole framework on one screen — every event with its timebox, who attends and what it produces — then covers the theory it rests on, each event in order along with the four meetings real teams add, the accountabilities and why the limit is ten, the Definition of Done and what happens when it stops short, five documented episodes, and where it degrades.
• ManagementKanbanKanban is a way of managing work that starts from your current process and improves it by limiting work in progress and measuring how that work flows. It adds no roles and no sprints. The page opens with every element of a Kanban system on one screen — what a team writes down and what its absence looks like — then covers why a board alone is not Kanban and the two bodies that define the method, its six principles and six practices, the four flow measures and the arithmetic under them, forecasting from history instead of estimates, the seven cadences, five documented cases, and where it degrades.
• ManagementAgileAgile is a set of four values and twelve principles for building software, written in 2001, that puts learning from working software ahead of the plan. It is not a methodology — Scrum, Kanban and Extreme Programming are the methodologies built on top of it — and it has no meetings, roles or artefacts of its own. The page opens with the Manifesto in full, numbered so a line can be cited, then covers the layer it occupies, what each value trades, the bet it makes on the cost of change, feedback loops as its real mechanism, each principle as a test you can run on your own team, six programmes it decided, and where it degrades into theatre.