Little’s Law is a single equation that relates how much work is in a system, how fast it arrives, and how long it stays: L = λW. The average number of items in a stable system equals the average arrival rate times the average time each item spends inside. It reads like an accounting identity, and the software world has flattened it into a productivity slogan. What makes it worth understanding is the part that gets lost: the proof holds under almost no assumptions, and the practice fails under a handful of specific ones. This note is about both. Its honest day-to-day use is as a consistency check on your flow metrics, not a forecast or a lever.
The surprising part is the generality
Philip Morse posed it first, in his 1958 book Queues, Inventories and Maintenance, essentially as a challenge: he noticed L = λW in specific queue models and asked readers to find a case where it failed. John Little answered in 1961 with a proof that no such case exists, published as “A Proof for the Queuing Formula: L = λW” in Operations Research. The result was not that the formula was handy. It was that the formula is nearly unkillable.
The relationship does not depend on the arrival distribution, the service-time distribution, the number of servers, the queue discipline, or the order in which items are handled. First-in-first-out, last-in-first-out, random, priority: same law. Little’s own 2011 50th-anniversary retrospective frames the conditions as almost embarrassingly weak. In its probabilistic form, if the three long-run averages exist and are finite and the system is stationary (its statistical behavior does not drift over the observation window), the equality holds exactly. Later “sample-path” proofs weaken even that, needing only that the limits exist, and derive the law from a single realized history of the system without any probability assumptions. This is why the same three letters describe a semiconductor fab, a hospital ward, a call center, and a Kanban board. It is a conservation statement, not a model of any particular process.
Two laws wearing one formula
The form software people quote is not the one Little proved, and the swap hides a subtlety. The flow version is average cycle time = average WIP / average throughput, which the WIP-limits note uses to show why capping work speeds it up. Rearranged, that is WIP = throughput × cycle time, structurally the same shape as L = λW.
The difference is what plays the role of λ. In Little’s original, λ is the arrival rate. In the flow version, throughput is the departure rate, how fast items finish. These are only equal when the system is stable, arrivals matching departures over the window. That equality is not a technicality you can wave through. It is the entire load-bearing assumption. If you use arrival rate while work is piling up, the cycle time you compute describes no item that will ever finish. The flow form is a special case of Little’s Law that quietly assumes the thing you most need to check.
Little’s Flaw: the assumptions that break it
Daniel Vacanti coined “Little’s Flaw” for the habit of plugging numbers into the flow equation when the conditions for it do not hold. The conditions, stated for a Kanban system:
- Arrivals roughly equal departures over the interval. The system is stable, not filling or draining.
- WIP is about the same at the start and end of the interval. You are not measuring across a ramp-up or a crunch.
- The average age of in-progress work is neither growing nor shrinking. Nothing is quietly getting old.
- Every item that starts eventually finishes. No silent cancellations leaving the count wrong.
- Consistent units for all three quantities.
The one that bites hardest is aging. Vacanti calls the failure mode “flow debt”: if you rush some items to completion by letting others sit and age, your measured average cycle time looks fine while a growing tail of stale work is invisible in the mean. The average is honest and the system is sick. Short observation windows in software, where work starts and stops in batches and items span reporting cycles, routinely violate the steady-state premise, and the formula reports a stable number for an unstable process.
It describes a system, it does not forecast an item
The most common misuse is asking Little’s Law a question it cannot answer: how long will this ticket take? The law is a statement about long-run averages. It says nothing about the distribution, so it cannot give you a probability for an individual item. A one-point story that clears in a day and one that grinds for three weeks can share a board whose average obeys the law perfectly. For forecasting a specific item or a specific date you need the spread, which comes from a cycle-time scatterplot or Monte Carlo simulation, not from the mean.
There is a second trap in the causal reading. “Lower WIP to lower cycle time” is true as an operating heuristic, but the law does not license it directly, because reading it that way requires you to hold throughput fixed while you vary WIP. In real teams throughput is not independent of WIP. Push WIP up and context-switching drags throughput down, so cycle time worsens faster than the linear formula suggests. The relationship the equation draws as a straight line is, in practice, non-linear. Little’s Law tells you the three quantities must stay consistent with each other. It does not tell you which one moves when you push another, and it does not promise the others stay still.
Try it
Check the law against your own board (1-2 hours, any Kanban tool with flow metrics). Pull throughput and average cycle time for the last month and multiply them to get implied WIP. Compare that to the actual average WIP on the board. Near steady state they match within a small margin. If implied WIP is well below actual, you have aging or flow debt: work is on the board that the throughput-and-cycle-time figures are not accounting for. The size of the gap is a direct read on how far your system is from the steady state the law requires.
Break it on purpose (30 minutes, a spreadsheet). Simulate a queue where you start 5 items a week but finish only 3. Track WIP and the true average time-in-system as the backlog grows. Now compute cycle time from the flow formula using arrival rate instead of departure rate. Watch the formula report a flat, comfortable cycle time while the real time-in-system climbs every week. That divergence is exactly the steady-state assumption failing, and it is why a green dashboard can sit on top of a drowning team.
See also
- Work-in-Progress Limits — the practical lever the flow form of the law justifies, with the worked WIP-to-cycle-time example
- Theory of Constraints — why throughput is set by the bottleneck, which is what caps the λ in a real system
- Software Estimation and Forecasting — where the “average, not a forecast” distinction matters most
- Drum-Buffer-Rope — scheduling flow around the constraint that governs throughput
Sources
- Little’s Law (Wikipedia) — the statement, the Morse-to-Little history, and the distribution-free conditions.
- Little, “Little’s Law as Viewed on Its 50th Anniversary,” Operations Research 59(3), 2011 — Little’s own account of the weak conditions and the sample-path proofs.
- Vacanti, “Little’s Law for Professional Scrum with Kanban” — the five assumptions, “Little’s Flaw,” and flow debt.
- “Don’t be fooled by Little’s Law” — the non-linear WIP-throughput relationship and why the law is not causal.