Little's Law (L = λ × W) links work-in-process, throughput and lead time in any stable queue or production system. Pick which variable to solve for, enter the other two, and get the answer instantly with consistent units (throughput in units/hour and lead time in hours give WIP in units).
Little's Law is one of the most powerful and general results in operations and queueing theory. It states that the long-term average number of items in a stable system (L, work-in-process) equals the long-term average arrival/throughput rate (λ) multiplied by the average time an item spends in the system (W, lead time): L = λ × W. It holds for almost any stable system — a factory line, a hospital ER, a software Kanban board, a call center, or a checkout queue — regardless of the arrival distribution or service order.
From L = λ × W you can rearrange to solve for any of the three variables:
WIP: L = λ × W (Throughput × Lead Time). If 8 units finish per hour and each spends 5 hours in the system, average WIP = 8 × 5 = 40 units.
Throughput: λ = L ÷ W (WIP ÷ Lead Time). If 40 units are in process and each takes 5 hours, throughput = 40 ÷ 5 = 8 units/hour.
Lead Time: W = L ÷ λ (WIP ÷ Throughput). If 40 units are in process and the line completes 8 per hour, average lead time = 40 ÷ 8 = 5 hours.
This calculator lets you pick the unknown and fills it in from the other two, guarding against divide-by-zero.
Little's Law only works when the time units of throughput and lead time agree. Throughput (λ) is a rate — items per unit time — and lead time (W) is a duration in that same time unit. If throughput is in units/hour, lead time must be in hours, and WIP comes out as a pure count of units.
A classic mistake: throughput of 8 units/hour with a lead time of 5 days. You must convert — 5 days × (working hours per day) into hours first, or convert throughput to units/day. This tool labels throughput as units/hour and lead time as hours so the WIP result is unambiguous; convert your real-world numbers to that basis before entering them, or scale consistently.
The most actionable insight is the lead-time form: W = L ÷ λ. Lead time is directly proportional to WIP for a fixed throughput. If you want to cut lead time in half without buying more capacity, cut WIP in half. This is the mathematical justification for limiting WIP in Kanban, reducing batch sizes, and the lean obsession with one-piece flow.
Conversely, piling on more WIP does NOT increase throughput in a capacity-constrained system — it just inflates lead time and inventory. Throughput is set by the bottleneck (see Theory of Constraints), so extra WIP beyond what the bottleneck needs only lengthens the queue. Little's Law makes this trade-off precise.
Little's Law requires only that the system be stable (stationary) over the averaging window — arrivals roughly equal departures, and WIP is neither growing nor shrinking without bound. It makes NO assumption about the arrival distribution, the service-time distribution, the number of servers, or the queue discipline (FIFO, LIFO, priority). That generality is what makes it so widely used.
It is an averages relationship, so it describes long-run behavior, not the instantaneous state at any single moment. Apply it over a meaningful window (a shift, a sprint, a month). In software it underpins flow metrics on Kanban boards; in manufacturing it links inventory, throughput and cycle time; in services it relates customers in the system, arrival rate and waiting time.
L is the average number of items in the system (work-in-process / inventory / customers in queue). λ (lambda) is the average throughput or arrival rate — items per unit time. W is the average time an item spends in the system (lead time, cycle time, or flow time). The law links them as L = λ × W.
No. That is its strength. Little's Law makes no assumption about the distribution of arrivals or service times, the number of servers, or the order in which items are processed. It only requires the system to be stable over the averaging period — meaning long-run arrivals equal long-run departures and WIP is bounded. This is why it applies equally to factories, hospitals, call centers and software teams.
Use the form W = L ÷ λ. For a fixed throughput, lead time is proportional to WIP, so reducing work-in-process directly reduces lead time. Halving WIP halves lead time. This is the theoretical basis for WIP limits in Kanban, smaller batch sizes, and one-piece flow. Adding more WIP does not speed things up — it only lengthens the queue.
Throughput is a rate (items per time) and lead time is a duration. Their time bases must match, or the multiplication is meaningless. Units/hour must pair with hours; units/day with days. If your data mixes bases — e.g. 8 units/hour and a 5-day lead time — convert one of them first. This calculator fixes throughput to units/hour and lead time to hours so the WIP output is always a clean unit count.
Not in a capacity-constrained system. Throughput is limited by the bottleneck resource. Beyond the WIP the bottleneck needs to stay fed, adding more WIP does nothing for throughput (λ stays flat) and only inflates lead time (W = L ÷ λ rises). This is a core lesson of the Theory of Constraints: manage WIP to the constraint, do not flood the system.