Why starting more finishes less
WIP = throughput × cycle time. Give any two and the third follows — and the result explains why limiting work in progress makes delivery faster rather than slower.
WIP = throughput × cycle time
Give any two and the third follows. The useful part is what it implies: cycle time falls when work in progress falls.
If you changed your WIP limit
What the law does and does not say
WIP = throughput × cycle time, averaged over a period.
It is exact — genuinely a law, not a heuristic — but only for a system in a steady state over the period you averaged: arrivals matching departures, nothing accumulating, and a consistent definition of what counts as in progress.
The arithmetic still returns a number when those conditions fail. If your backlog is growing, if items are being abandoned rather than finished, or if "in progress" quietly changed meaning halfway through the quarter, the answer is arithmetically correct and describes nothing.
Why starting more things finishes fewer
Rearrange the law and it says something uncomfortable: at a fixed throughput, cycle time is proportional to work in progress. Double the number of things underway and everything takes twice as long to finish.
This is the argument for WIP limits, and it is arithmetic rather than philosophy. A team with twenty items in flight and a throughput of five per week has a four-week cycle time. The same team with ten in flight has a two-week cycle time. Nobody worked faster; the queue got shorter.
The instinct when a stakeholder asks for something is to start it. The law says that starting it makes everything already underway finish later, including the thing they asked about last month.
Throughput is what you finish, not what you touch
The single most common way to get this wrong is to count work started rather than work completed. Half-finished work has consumed capacity and delivered nothing, and counting it flatters the numbers in exactly the situation where you most need them to be honest.
It will not tell you what to do about a bottleneck
The law relates three quantities. It has nothing to say about why your cycle time is what it is, where work waits, or which stage is starved. For that you need the flow data itself — the queues between stages, and how long items sit in each.