Why Kanban works · chapter 3 of 5 · 5 min
Why limits work
Three numbers on a wall halved a team's wait. That is either magic or something with a mechanism underneath it, and it is the second. This chapter is the mechanism: where the wait comes from, the one equation that says how long it is, and how small the limits should be.
From here on the workflow is a small one, so that every change can be watched: Specify takes a day, Implement takes a week, Validate takes a day, one person on each, and a backlog that never runs dry.
Watch a queue form
Here is the workflow with nothing limiting how much work may be in a step, which is how most teams start, because it is what you get when nobody decides otherwise. Everyone works as soon as they are free. Watch it for half a minute: a dot fills as it is being worked on, and a dashed dot is one nobody has picked up.
an item, filling as it is worked · waiting for someone · the people on the step, lit while they have work
Specify hands on an item a day. Implement can take one a week. Validate is empty most of the time. Six weeks is enough: by then the pile has stopped being a number anyone can hold in their head, which is rather the point.
Nobody had to say "there is a queue in front of Implement": you saw it form. Nobody had to say "Validate is starved", or "Specify is busy producing work nobody can take". That is what a wall is for: it shows a workflow going wrong while it is going wrong, rather than at the end of the month when it has become self-evident.
Two things to keep hold of. The pile is not harmless: everything in it is work started and not finished, which is what makes an answer slow. And however big it grows, the number of items finished a week never moves: the queue buys nothing at all.
Little's Law
One equation governs every workflow, and nothing can be done about it:
work in progress = throughput × response time
Finish two items a week with six on the go, and an item takes three weeks. So the only two ways to answer faster are to carry less or finish more. That is the whole of it, and it is where WIP limits come from.
Here is the same workflow as the one above, with one change: each step may hold one item. Nobody works faster. Nothing is automated. The only difference is that Specify is not allowed to start a seventh thing while six are already waiting.
an item, filling as it is worked · waiting for someone · the people on the step, lit while they have work
2.2 in progress = 1.0 a week × 2.2 weeks Little's Law, measured — not asserted. It balances because it must.
Six weeks of each, side by side:
| After six weeks | No limits | One item per step |
|---|---|---|
| Items finished a week | 0.8 | 0.8 |
| Work in progress at the end | 25 | 2 |
| Wait for something started now | 30.0 weeks | 2.4 weeks |
The same number of items finished. The limit made nobody faster and finished nothing extra: Implement was the ceiling in both, and it still is. What it changed is everything else: 25 things on the go against 2, and a wait of 30 weeks against 2.4. Divide one by the other and you have Little's Law: the wait is the pile divided by the pace. Work you start before the team can take it does not arrive sooner; it waits, and it makes everything behind it wait too.
The equation under the board is computed from the run: the three figures are measured separately, never told about each other, and they balance anyway. A whiteboard would say 3 weeks here, three items in progress at one a week; the run says about 2.2, because Validate stands empty four days in five and the average WIP is nearer 2 than 3. Both are Little's Law; one counts the limits and the other counts reality. Named after John D. C. Little, who proved it in 1961.
How small should the limits be?
The smallest possible WIP is one item per step, and by Little's Law that gives the fastest possible response time for a given throughput. Lean calls it single-piece flow. It is the theoretical ideal, and it is rarely what a team should do.
Look at the board above again: two people in three are idle most of the time. Work varies (some items are hard to specify, some hard to build, some hard to check) and with no slack anywhere, that variation turns into people waiting. A little buffer keeps them working and the team finishing more. The trick is to make the limits as small as you can bear, with enough give left in them.
Where to leave that give is not a matter of taste. One step in this workflow sets its pace (Implement, the week-long one), and the slack belongs in front of that step and nowhere else. That step is the next chapter.