Kanban

A board is not Kanban

Let us begin with the thing that surprises most people. Almost every team that says "we use Kanban" has a board with columns and nothing else. That is not Kanban. That is a board.

A board makes work visible. That is genuinely useful, and it is where every team starts. But visibility on its own changes nothing: you can watch a queue grow just as easily as you can watch it move.

Kanban adds one mechanism on top: an explicit limit on how many items are allowed in each column at the same time. That limit is called a WIP limit — WIP stands for work in progress, meaning everything that has been started but not finished.

Now here is why that one rule matters so much. Without it, the board is a queue that can grow forever — when you are blocked, you simply start something new. With it, the board pushes back. You cannot start anything until something finishes, so the team is forced to go and unblock whatever is stuck rather than route around it.

The six practices

The Kanban Method defines six practices. They are meant to be adopted in order — each one becomes possible because of the one before it. Here is each, and what it asks you to actually do.

1. Visualise the workflow

Draw the stages your work actually passes through — not the ones in the process document. Most teams discover two or three stages they never named, and those are usually the waiting ones: "waiting for review", "waiting for the client", "waiting for deployment".

Those hidden waiting stages matter more than the working ones. In most teams an item spends far more of its life waiting than being worked on, and you cannot improve time you cannot see.

2. Limit work in progress

This is the one practice with no room for compromise. Put a number at the top of each column and hold to it.

A reasonable starting point is one and a half items per person in the column — for a team of four, a limit of six on the "in progress" column. Then lower it until the team feels the constraint. Feeling it is the point: if nobody ever hits the limit, the limit is not doing anything.

3. Manage flow

Optimise for how quickly work crosses the board, not for how busy people look. These two goals conflict more often than teams expect.

A team where everyone is one hundred percent busy has no slack, and with no slack every small disruption turns into a delay. Some idle time is not waste — it is what lets the team respond when something gets stuck.

4. Make policies explicit

Write down what it takes for an item to enter each column and to leave it. What does "ready for development" mean? What must be true before something moves to "done"?

Unwritten rules are applied inconsistently, and the inconsistency is invisible until it causes an argument. Written policies also let anyone on the team move a card without asking permission, which is what makes the board self-service rather than something one person maintains.

5. Implement feedback loops

This is the practice most teams skip entirely, and it is where the seven cadences live. We will cover them in their own section below, because there is more to say than fits here.

6. Improve collaboratively

Change the system based on what the measurements show, not on the loudest complaint. The metrics section below gives you the numbers to argue from.

The seven cadences

Kanban is often described as "the method with no meetings", and that is wrong. It has no mandatory meetings, which is a different claim. The method actually defines seven regular feedback loops, called cadences.

Almost every team adopts the first two and never learns the other five exist. That is a real loss, because the fast loops only manage the work in front of you — the slow ones are what stop a team from getting very efficient at doing the wrong thing.

Let us go through them from fastest to slowest.

You do not need all seven from day one. Start with the daily and the replenishment meeting, then add the service delivery review once you have a month of metrics worth discussing. The rest come as the organisation grows around the team.

The metrics, and why they work

Kanban replaces estimation with measurement. Instead of asking how long a task will take, you observe how long tasks actually take and forecast from that history.

The difference between cycle time and lead time is worth pausing on, because teams routinely report one and mean the other. Cycle time starts when someone begins working. Lead time starts when the customer asks. The gap between them is how long requests sit in a queue before anyone touches them — and in many teams that gap is the larger half of the customer's experience.

Little's Law — the argument for WIP limits

There is a piece of mathematics underneath all of this, and it is simple enough to state in one line.

Average cycle time equals work in progress divided by throughput. That is Little's Law, and it holds for any stable queue — supermarket checkouts, hospital wards, software teams.

Now look at what it implies. Throughput is bounded by your team — you cannot double it this week by wanting to. So if you want work to finish faster, the only variable you can move quickly is WIP. Halve the number of things in progress and, all else equal, cycle time roughly halves.

The cumulative flow diagram

One chart deserves its own mention because it shows all of the above at once. A cumulative flow diagram plots, for every day, how many items are in each stage — drawn as coloured bands stacked on top of each other.

You read it by looking at the shape of the bands rather than the numbers. A band that keeps widening is a stage where work arrives faster than it leaves — that is your bottleneck, and it is visible weeks before anyone would have complained about it. Bands that stay a steady thickness mean the system is in balance.

Classes of service

Here is a question every team hits within a month of adopting Kanban: what do you do when something genuinely urgent arrives and the column is at its limit?

The method has a defined answer, and it is not "raise the limit". You agree in advance on a small number of classes of service — categories of work, each with its own rules — so that the decision is made once, calmly, rather than argued each time under pressure.

• Expedite — drop everything

  Production is down, money is being lost. Ignores the WIP limit and jumps the queue. Keep a strict cap — commonly one at a time — or every request becomes an expedite.

• Standard — the default

  Ordinary work. Pulled in order, obeys the WIP limit, forecast from measured cycle time. The large majority of items should be here.

• Fixed date — a real deadline

  Has a genuine external date: a regulation, a contract, a campaign launch. Scheduled backwards from that date rather than pulled when it reaches the front.

• Intangible — no urgency, real value

  Refactoring, upgrades, paying down technical debt. No deadline and no visible customer, so it is picked up when there is slack — and it is what stops the system degrading.

Kanban next to Scrum

The two are not rivals, and teams routinely use both. But they do make one structurally different choice, and understanding it makes the decision straightforward.

The practical rule is about how often your priorities genuinely change. If they can hold steady for a fortnight, a sprint goal gives the team something to align around and Scrum fits. If urgent work arrives several times a week, a sprint goal will be broken most weeks anyway — and Kanban stops you pretending otherwise.

And if you want the rhythm of Scrum with the pull mechanics of Kanban, that hybrid has a name and a page of its own: Scrumban.

How this shows up in real delivery

The moment a team adopts a real WIP limit, its first reaction is discomfort. People find themselves blocked with nothing "of their own" to start, and it feels like standing around.

That discomfort is the method working. It has converted an invisible queue into a visible conversation about the bottleneck. Before the limit, the same person would have started a fifth task and the blockage would have stayed exactly where it was — just with more unfinished work stacked behind it.

Where it degrades

• A board with no WIP limits — the most common case by far, and it is not Kanban.
• A limit that is raised whenever it is hit, which removes the only forcing function.
• A "blocked" column used as a parking lot, so blocked items stop counting against WIP.
• Only the two fast cadences adopted, so nobody ever asks whether the work is the right work.
• Everything marked expedite, which makes the queue meaningless and the forecast wrong.

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.
• ManagementScrumbanScrumban is Scrum's rhythm with Kanban's pull mechanics. You keep the planning cadence and the retrospective, drop the sprint commitment, and refill the board when it runs low instead of on a calendar. Most teams that say "we do Scrum, but flexibly" are describing this — and naming it properly is what turns a quiet erosion of Scrum into a deliberate design.
• 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.