Limiting work in progress

Why does forbidding people to start new work make more work get finished?

A team is behind. The obvious response is to start more things: more items in flight means more chances something lands. Nobody is idle, the board is full, and every stakeholder can see their request has been begun.

Then someone imposes a rule that no more than four items may be in progress at once, and forbids anyone from starting a fifth. Less is being worked on. Delivery goes up. This is not a morale effect or a focus platitude — it shows up in throughput counts. So something in the first arrangement was consuming capacity without producing output, and the second arrangement stopped it. What was it?

Start with the one relation here that is not a matter of opinion. Little's Law says that for any stable queueing system, the average number of items in it equals arrival rate times the average time an item spends there. Rearranged for a team: cycle time equals work in progress divided by throughput. It is an identity over long-run averages, not a model with assumptions about the work.

Read it carefully and notice what it does not say. It does not say that raising work in progress raises throughput. Throughput sits on the other side. If throughput were fixed, doubling the number of items in flight would double how long each takes and deliver precisely the same number per week — everything simply later. Starting more things would be pure loss of responsiveness with no gain at all.

So already the intuition is in trouble. But this is the merely-neutral case. The real question is whether throughput is in fact independent of work in progress, and it is not. Three mechanisms push it down, and they are worth separating because they have different remedies.

The first is switching. A person holding six items does not work six at a time; they alternate, and every resumption costs the reconstruction of context. This cost is real and repeatedly measured in task-switching studies, though the widely quoted percentages for "time lost per additional task" trace back to a single practitioner's illustration rather than a controlled experiment.

The second is queueing at shared resources. Suppose ten items are in flight and all must pass one reviewer. Starting an eleventh does not make the reviewer faster — it lengthens the queue. Utilisation is the sharp point: as a resource approaches full occupancy, waiting time rises non-linearly, so the last few percent of "keeping everyone busy" buys an enormous increase in delay. This is why systems designed for responsiveness deliberately run their bottlenecks below capacity.

The third is aging, the least visible. An item in flight for a long time decays — requirements shift under it, the person who asked drifts away, a dependency changes, merge conflicts accumulate — and some of that work must be redone or is discarded. Work in progress is inventory, and this inventory spoils, so a long cycle time does not just delay output, it destroys some of it.

Now put the three together with the identity. High work in progress lengthens cycle time by arithmetic; long cycle time lowers throughput by switching, queueing, and spoilage; and lower throughput lengthens cycle time further for the same work in progress. That is a reinforcing loop, and it is why the degradation feels sudden rather than gradual — you are past a knee, not on a slope.

What does the limit actually do to break it? Its purpose is not to reduce workload — demand has not changed. Its purpose is that when the limit is reached, starting is prohibited, so the only legal action is to help finish something already in flight, forcing the team to converge on the constraint instead of routing around it. The limit also makes that constraint visible: if work piles up in front of one column, that column is your bottleneck, as an observation rather than an opinion.

So the counterintuitive framing dissolves. You are not choosing to do less work. You are choosing to hold less work, which is a different thing entirely — and it is the holding, not the doing, that was consuming the capacity.

The misconception to correct is that this is about focus or discipline. It is a capacity argument: even a team of perfect multitaskers with zero switching cost would gain nothing from higher work in progress, because Little's Law would stretch every item's cycle time while throughput stayed put. Switching cost turns a neutral change into a harmful one; it is not what makes the intuition wrong.

Two refinements. First, a limit that is too low is also a real failure — if the number is set below what the workflow can genuinely parallelise, people are idle with no legal item to pull, and idleness is not free either. There is no formula for the right number. The usual practical approach is to start near the number of people, then lower it until blocking becomes frequent enough to be informative but not paralysing, treating the limit as a dial to be tuned by observation.

Second, the identity holds only for a stable system, where arrivals and departures balance over the window. If demand genuinely exceeds capacity, no limit fixes it — it merely moves the growing queue from inside the team to outside, where it is visible and can be prioritised or refused. That relocation is often mistaken for a fix; it is a diagnosis.

One honest caveat: the evidence for work-in-progress limits is strong in manufacturing and repeatedly reproduced in team-level metrics, but knowledge work varies enough between contexts that "limit WIP and throughput rises" is a well-supported operational heuristic rather than a law with a measured coefficient.

• Why queueing delay rises non-linearly as utilisation approaches one, and what that implies about planning any bottleneck to be fully busy.

Every term the collection defines is gathered in the glossary.