Scrumban

Why this exists at all

Scrumban is not a framework with a guide, a certification or an owning body. It is a name for a specific trade that a lot of teams end up making, and having the name matters more than it sounds.

Here is the situation it solves. A team runs Scrum properly. Then production incidents start taking half its capacity, and it misses the Sprint Goal three sprints in a row. Nobody did anything wrong — the goal was simply never realistic given the interruptions.

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.

How the hybrid is assembled

The board is Kanban: columns with explicit WIP limits, work pulled left to right. The rhythm around it is Scrum: a regular retrospective, a daily meeting, a periodic review.

The one structural change is when planning happens. In Scrum, planning fires on a date. In Scrumban, it fires on a number: when the ready queue drops below a threshold, you hold a short session and refill it.

What survives, what changes, what goes

This is the part teams get wrong most often, because "we dropped the sprint" tends to become "we dropped everything". Let us be specific about each ceremony.

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.

2. The replenishment trigger

This is the number that replaces the sprint start. When the ready queue holds fewer than N items, planning is called.

3. The retained cadence

Decide which Scrum meetings stay and put them in the calendar as recurring events. The retrospective is mandatory. The daily and a periodic review are usually worth keeping. Planning becomes on-demand.

Bucket planning — the longer horizon

One question comes up as soon as the sprint goal disappears: how do you plan anything beyond the next two weeks?

Scrumban has an answer borrowed from lean manufacturing, called 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 replenishment meeting 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.

Where it sits between the two

How this shows up in real delivery

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.

The reason to announce it matters: stakeholders 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.

Where it degrades

• 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 replenishment threshold, so planning happens when someone remembers and the queue runs dry.
• The retrospective lapsing because no sprint boundary forces it into the calendar.
• Adopted to escape the discipline of Scrum rather than to fit the shape of the work.

When to use it

Related pages

• ManagementScrumScrum is the most widely used way of organising a software team. Scrum breaks work into short, fixed cycles called sprints, gives three people clear areas of responsibility, and puts a small set of regular meetings around the work so problems surface within days instead of months. This page walks through every one of those meetings — including several that real teams hold but the official guide never mentions.
• ManagementKanbanKanban is a way of managing work that starts from the process you already have and improves it under measurement. Kanban adds no roles and no sprints. It adds one rule — a cap on how many things you may work on at once — and that single constraint is what makes everything else in the method work. This page covers the board, the metrics, the seven regular meetings the method defines, and how to set that cap in practice.
• ManagementAgileAgile is a way of building software that assumes you will be wrong about something and plans for finding out early. Agile is not a process you install and not a set of meetings — it is a small group of beliefs, written down in 2001, that a dozen different methodologies are built on top of. This page explains those beliefs, all twelve principles behind them, and what actually changes in a team that takes them seriously.