This is Little’s Law, proved by John Little in 1961. It holds exactly for any process — regardless of how variable the work is, how items are prioritised, or what the size distribution looks like. It describes long-run averages, so it needs almost no data: count what’s in flight, count what finishes, and the third quantity is fixed.
Unlike Kingman’s formula — which predicts queue time from utilisation and variability — Little’s Law ties the three numbers together without explaining why cycle time is what it is. Know any two and the third is determined.
- WIP
- The number of items inside the process at once: committed, started, not yet done. Everything between the commit line and the finish line.
- Throughput
- The rate at which items leave the process — items finished per unit of time. Also called delivery rate. Measured at the exit, not the entrance.
- Cycle time
- The average time one item spends inside the process, from commit to done. Touch time plus all the time it spends queuing between stages.
- Stable process
- One where, on average, work leaves as fast as it arrives — the queue isn’t growing without bound. The law holds for averages over a period where this is roughly true.
live check: throughput × cycle time = 6.0 · measured WIP = 6
Start at WIP = 6 and capacity = 1.4 items/s. Cycle time settles near 4.3 s. Now test what the law predicts.
-
Halve the WIP limit to 3cycle time roughly halves
Throughput barely moves — the team finishes work at about the same rate. But cycle time roughly halves. Less work in flight means each item waits behind fewer others. ↺ reset before the next step.
-
Reset, then push WIP up to 16only buys delay
Throughput is flat — you can’t finish faster than capacity allows — so the extra work-in-progress turns entirely into cycle time. The board fills with queuing (red-outlined) items. More WIP buys you nothing but delay. ↺ reset before continuing.
-
Reset, then raise throughput capacity insteadcycle time falls too
Now cycle time falls and you keep the same WIP. Growing real capacity — better tooling, automation, skill — is the other way to cut cycle time. It’s just far slower and more expensive to move than a WIP limit, which you can change this afternoon.
What WIP means on a dev team
Count every ticket a developer has started but not shipped. Add the PRs sitting in review. That total is your WIP — check it: it’s usually higher than the team thinks.
The law is then a readout. If the team ships 2 tickets a day and 10 are in flight, every ticket waits 5 days on average. Cut in-flight to 5 and cycle time halves. Same team, same capacity, same people — the work didn’t get simpler, there’s just less of it queued behind itself.
It also runs the other way: know WIP and throughput and you can predict cycle time before you measure it. If that number is higher than anyone expected, the cause is on the board in front of you.
Stop starting, start finishing
Under pressure the instinct is to pull more in — more tickets, more fronts, more visible activity. Little’s Law says what that does. Throughput is capped by capacity, so it doesn’t rise. With throughput fixed, the law rearranges to:
Every extra item you admit lands in the numerator. Cycle time rises with it. You don’t finish anything sooner; you just have more things half-done for longer. At a fixed capacity of 1.4 items/s:
| WIP | Throughput | Cycle time | Effect |
|---|---|---|---|
| 3 | 1.4 | 2.1 s | fast flow |
| 6 | 1.4 | 4.3 s | baseline |
| 12 | 1.4 | 8.6 s | 2× slower |
| 16 | 1.4 | 11.4 s | 2.7× slower |
Same team, same delivery rate, nearly three times the wait — bought entirely by letting too much in.
The pattern plays out whenever intake exceeds throughput. Pull 12 items per week when the team ships 8, and 4 carry over every cycle — WIP accumulates and never drains. Cycle time stretches, the board fills, the team works harder while shipping less. Pull only what can clear.
When cycle time is slow, count WIP first
The usual diagnosis for slow delivery is complexity or capacity. Both may be true, but neither tells you what to do today. WIP does.
Open the board. Count every card not in Done. Divide by daily throughput. That’s the predicted cycle time. If it’s higher than expected, that’s why things are slow — and cutting WIP is an immediate fix, not a multi-quarter investment.
Tickets that hit a blocker get set aside while new work comes in around them — sitting in “In Progress” indefinitely. The board looks busy; delivery is slow. Stop pulling new work and clear the blocked tickets: deprioritise, descope, or close them.
The WIP limit
A WIP limit caps how many items can be active at once. It’s the only input in the equation you can change today — for free, with same-day effect on cycle time.
Growing throughput means automation, better tooling, clearing tech debt, or hiring — months of work at best. A WIP limit is a team decision. Two tickets per developer in progress is a common starting point; the exact number matters less than having one at all. Teams that start from no limit usually see cycle time drop faster than expected, because WIP turns out to be higher than anyone counted.
The limit doesn’t slow the team down. It makes the team say “finish the PR in review before picking up the next ticket.”
How this sits with Kingman
Little’s Law is a fixed mathematical relationship: cut WIP and cycle time falls, exactly and always — but it doesn’t tell you how low cycle time can go, because it treats throughput as a given.
Kingman’s formula explains what sets that floor. Cycle time is touch time plus queue time, and Kingman predicts the queue time from utilisation and variability. It tells you why work waits even when WIP is modest.
Little’s Law says reduce WIP and cycle time falls. Kingman says the variability and load determine how much queuing is baked in underneath. A WIP limit is the instrument that acts on both — it caps the work in flight (Little) and smooths how work is pulled in (Kingman).
Takeaways
- — WIP = Throughput × Cycle time, always. It’s a mathematical law, not a guideline. Know any two and the third is determined — no exceptions for team size, process, or complexity.
- — Cycle time follows from WIP and throughput. Control those two; cycle time is whatever they make it.
- — When delivery is slow, count WIP first. Open the board, count the cards not in Done, divide by daily throughput. That’s your predicted cycle time. If it’s high, that’s why.
- — Starting more work makes delivery slower. Extra WIP can’t raise throughput past capacity, so it turns directly into delay. More in progress, nothing done sooner.
- — A WIP limit is the only lever you can pull today. Throughput takes months to grow. A WIP limit is an afternoon decision with immediate effect on cycle time.
- — Pairs with Kingman. Little tells you WIP controls cycle time. Kingman tells you what sets the floor — the load and variability baked into the process.