Kanban

A Kanban system on one screen

Here is the whole method first. Kanban prescribes no meetings you must hold and no roles you must fill, so what defines a Kanban system is what the team has written down — twelve decisions, each of which fits on one line. The table lists them in the order a team usually makes them, with an example from a team of five, and what the board looks like when the decision was never made.

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.

The word itself explains why. Kanban is Japanese for a signboard or a card. On Toyota’s lines, where Taiichi Ohno tried the system in the machine shop in 1953 and spread it across the company by 1962, the card was not a description of a task. It was permission to produce. A station built parts only when a card came back from the station downstream, so the number of cards in circulation was the limit on inventory: no card, no production.

Software boards turned that around. On a board the card is the work item itself, so the permission has to be written separately — as a number at the top of each column. That number is called a WIP limit. WIP stands for work in progress, meaning everything that has been started but not finished. A board without the number has kept the picture and dropped the mechanism.

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.

Two bodies define it, and they disagree on how much

A reader who looks for the official definition finds two, and much of the confusion about Kanban comes from mixing them. Kanban University, which David J. Anderson co-founded, publishes the Kanban Method — the approach Anderson developed at Microsoft from 2004 and at Corbis from 2006, and described in his 2010 book. ProKanban.org publishes The Kanban Guide, first issued in July 2020 and current in its May 2025 edition: a deliberately minimal text by Daniel Vacanti, John Coleman and others.

Neither is wrong, and this page uses both: the Guide’s four measures and its service level expectation, because they are the sharpest tools for forecasting, and the Method’s principles, cadences and classes of service, because a team that only measures flow has nothing that tells it whether the flow is pointed anywhere useful. Where the two use the same word differently, the page says so.

Six principles, six practices

Most descriptions of Kanban list the practices and skip the principles. That is a pity, because the principles explain why the practices can be introduced so gently. Kanban University names three principles about change and three about the service a team provides.

The six practices are what the principles look like in use. They are meant to be adopted roughly in order, each one becoming possible because of the one before it.

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. Draw the commitment point as a line too. Kanban University calls everything before it upstream: ideas and options that may still be discarded, which is exactly why they must not count as promises.

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, and the measures section below shows the arithmetic of why.

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. They have their own section below, because there is more to say than fits here.

6. Improve collaboratively, evolve experimentally

Change the system based on what the measurements show, not on the loudest complaint. Treat each change as an experiment: say in advance what it should do to a measure — "lowering the review limit to two should cut cycle time" — and check a month later whether it did. A change nobody predicted anything about cannot be learned from.

Classes of service — urgency written as a policy

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.

Each class stands for a different shape of cost of delay — what one more day of waiting costs. For an outage it is high from the first minute. For a regulatory date it is nothing until the date and everything after it. For ordinary work it grows steadily. For an upgrade nobody asked for it is nothing today and a great deal in a year, which is exactly why that work loses every argument unless a policy protects it.

• 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. Started early enough that the 85th-percentile cycle time still lands before the 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.

A second policy sits beside classes of service: capacity allocationcapacity allocationthe WIP limit split between kinds of workDividing a team’s work-in-progress limit between kinds of work in advance — say five planned items, three support requests and one improvement — usually drawn as separate lanes on the board. The split is argued once rather than for every request, and when it proves wrong the measures show it.Full article →All terms, which splits the WIP limit between kinds of work so that unplanned requests cannot swallow the planned work, nor the other way round. It matters most on teams that mix a roadmap with support, and the Scrumban page draws it out lane by lane.

Four measures, and the arithmetic under them

Kanban replaces estimation with measurement. Instead of asking how long an item will take, you observe how long items actually take and forecast from that history. The Kanban Guide makes four measures mandatory, and each one answers a different question.

Now the terminology trap, because teams routinely report one number and mean another. This page uses cycle time for the span from started to finished, as the Kanban Guide does. Lead time here is the customer’s span, from request to delivery; Kanban University’s customer lead time runs from the commitment point to delivery instead. The gap between a request and the start of work is how long it sat in a queue before anyone touched it — and in many teams that gap is the larger half of what the customer experiences. When someone quotes a number, ask where the clock started.

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 average work in progress divided by average 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.

One caution, because the law is quoted far more often than its conditions. John Little proved it in 1961 for averages over a period in which the system is stable, and a team’s board is only roughly that. It holds when four things are true — and each of them is a policy the team controls.

That is why the law is best used to understand the system rather than to forecast from it. It proves that halving WIP must shorten cycle time; the date for a particular item is better read off the team’s own history, as the next section shows.

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 have entered each stage so far, drawn as coloured bands stacked on top of each other. Its geometry is Little’s Law drawn: the vertical distance between two lines is the WIP between them, the horizontal distance is roughly how long an item spends between them, and the slope of the bottom line is throughput.

You read it by 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. A flat top line means nothing new is being started; a flat bottom line means nothing is being finished. Bands of steady thickness mean the system is in balance.

Why a fully busy team is slow

The second piece of arithmetic is the one managers resist most. In a queue, the wait before work starts does not rise in proportion to how busy the people are. It rises with the busy share divided by the idle share. In the textbook single-server queue, the wait is utilisation divided by one minus utilisation, counted in average tasks:

Real teams differ from the textbook in detail, but the shape is general, and Donald Reinertsen built much of "The Principles of Product Development Flow" (2009) on it: the last ten percent of utilisation costs more waiting than the first eighty. That is the arithmetic behind the third practice. Slack is not waste; it is what keeps the queue short.

Forecasting from history instead of estimates

Here is the question every stakeholder eventually asks a Kanban team: when will it be done? The method’s answer is to stop estimating individual items and read the answer off the team’s own history, which has been recording the truth all along.

Plot every finished item as a dot: when it finished along the bottom, how long it took up the side. That is a cycle time scatterplot, and three horizontal lines turn it into a forecast. The 50th percentile is the time half of all items beat. The 85th is the time most items beat, and the usual basis for a promise. The 95th is the time almost all of them beat.

The team then publishes a service level expectation, abbreviated SLE: a duration and a probability, such as "85 percent of items finish within 11 days of starting". It is not a target and not a contract. It describes what the system has been doing, and it changes when the system does.

Now the useful part. Work item age — how long an item still in progress has been in progress — can be compared with the SLE every morning. An item whose age is approaching the 85th percentile is at risk while there is still time to act: swarm it, split it or unblock it. Cycle time tells you an item was late after it finished; age tells you it is going to be late while it can still be saved. That is why the Kanban Guide made it one of the four mandatory measures.

Seven cadences — and where Scrum’s events fit

Kanban is often described as "the method with no meetings", and that is wrong. It has no mandatory meetings, which is a different claim. Kanban University 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.

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

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. 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.

Five documented cases, and the rule each one tested

Kanban has a longer paper trail than most methods, because it began on a factory floor and entered software through a handful of well-documented teams. The first four show the limit working. The fifth shows its price.

Where it degrades

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 — with more unfinished work stacked behind it.

The honest limit: Kanban makes the flow of the work already in the system fast and predictable, and it has nothing to say about whether that work is worth doing. The strategy review is the only cadence that asks, and it is the one most teams never hold. Kanban also cannot fix a dependency outside the board — a WIP limit on your review column does nothing about the platform team whose approval every item waits for — and it forecasts badly when items vary so much in size that the history predicts nothing.

• 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.
• Cycle time turned into a target for individuals, so items are split to look fast and closed before they are finished.
• The clock started at "In progress", which hides the queue in front of it — the part of the wait the customer feels most.
• Averages reported instead of percentiles, so about half of all promises are broken.
• "We do Kanban" used to mean "we do not plan": no replenishment, no SLE, and no review of what enters the board.
• The tool’s default columns adopted as the workflow, without anyone mapping the stages the work actually passes through.

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.
• ManagementScrumbanScrumban is a way of running a team that keeps Scrum’s regular meetings but swaps the sprint commitment for Kanban’s WIP limits and planning on demand. Corey Ladas coined the name in 2008 for a path from Scrum toward continuous delivery; most teams now use it for a stable hybrid. The page opens with every Scrum element and what becomes of it, then covers why the hybrid exists, the two meanings of the word, the three numbers that define it, how planned work and interrupts share one board, planning beyond the next fortnight, a side-by-side with its parents and one measured switch, 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.