skip to content

How does Little's Law relate work in progress, throughput and cycle time, and when does it hold?

level: middleimportance: must knowfreq 62%

answer

  1. Three averages, one relationship
  2. Multiply two of them for the third
  3. Items in progress, rate, duration
  4. Only valid on a stable window
  5. Nothing may vanish from the system

basics

~20 s

Little's Law says average work in progress equals average throughput multiplied by average cycle time. It holds over a window where the system is stable, arrivals roughly match departures, nothing entering is abandoned, and all three averages share one boundary.

solid answer

~40 s

The law relates three averages measured over the same window: **average work in progress = average throughput × average cycle time**. The useful rearrangement is cycle time = work in progress ÷ throughput, because counting items on a board and counting completions is cheap while timestamping every item is not. It holds only under stability: arrivals and departures roughly balance so work in progress is not trending, everything that enters eventually leaves rather than being abandoned, all three figures describe the same start and end boundary, and the units agree. Note what it is not — throughput is what *did* finish, not the team's capacity, and the law relates averages, so it makes no promise about any individual item and does not by itself prove causation.

code

pseudocode · 8 lines
pseudocode
window            = 15 working days
finished_items    = 36
throughput        = finished_items / window        # 2.4 items per day
average_wip       = 18                             # board counted daily, then averaged
average_cycle     = average_wip / throughput       # 7.5 days

# cross-check against per-item measurements
# a large disagreement means an assumption is broken

go deeper

for a junior

Recall the relationship and the three terms with their units: a count of items, a rate per unit time, and a duration. Being able to rearrange it to get cycle time is enough at this level.

for a middle

Explain the mechanics and do the arithmetic aloud, then name the stability and conservation assumptions. Expect a follow-up on why a growing queue makes the answer meaningless.

for a senior

Demonstrate that you cross-check the derived cycle time against measured values and treat a disagreement as evidence of stale or abandoned work rather than a rounding issue. Be ready to say what you would inspect first.

for a principal

Own the limits: the law is a relationship between averages, not a causal lever or a forecast. Be ready to explain why an organisation that manages to a derived number without checking stability is measuring nothing.

## The law in one line Little's Law relates three averages measured over the same window and inside the same boundary: **average work in progress = average throughput × average cycle time** - **Work in progress** is a count — how many items are inside the boundary you drew, sampled repeatedly across the window. - **Throughput** is a rate — items crossing the exit boundary per unit of time. - **Cycle time** is a duration — how long an item spends inside the boundary. In practice the rearranged form does the work: **average cycle time = average work in progress ÷ average throughput**. Counting items on a board and counting completions are both cheap; timestamping every item individually is not, so the law lets you derive the expensive measure from the two cheap ones. ## Units are half the battle | Term | What it is | Unit | How it is measured | |---|---|---|---| | Work in progress | items inside the boundary | items | sample the board daily, then average | | Throughput | completions per unit time | items per day | count exits over the window, divide by its length | | Cycle time | time spent inside the boundary | days | the value the law returns, or measured per item | Mixing units is the most common arithmetic error: quoting throughput per week against a cycle time in days produces an answer that is wrong by a factor of the week. ## A worked window A team on a construction-site safety product measures one 3-week window of 15 working days. It finished 36 items, and a daily count of the board averaged 18 items in progress. - throughput = 36 ÷ 15 = **2.4 items per day** - average cycle time = 18 ÷ 2.4 = **7.5 days** The useful move is then to cross-check that 7.5 against directly measured per-item cycle times. If the measured average comes out far lower — say 4.6 days — the gap is evidence that an assumption is broken, and the usual culprit is a handful of ancient items sitting on the board inflating the work-in-progress count without ever contributing a completion. ## The assumptions that must hold 1. **Stability over the window.** Arrivals and departures roughly balance, so the amount of work in progress is not trending sharply up or down. A queue that grows all quarter has no meaningful average. 2. **Conservation.** Everything that enters eventually leaves. Items silently abandoned, deleted, or parked forever break the arithmetic, because they entered the count but never produced a completion. 3. **A consistent boundary.** All three averages must describe the same start and end points. Measuring work in progress across the whole board while counting throughput at one column's exit gives a number that means nothing. 4. **The same window for all three.** The law is a relationship between averages over one period, not a mix of this month's throughput and last quarter's item count. 5. **Consistent units, consistently stated.** Items and days, or items and weeks — never one of each. Note what is *not* on the list: nothing requires items to be the same size, nothing requires iterations, and nothing requires a cap on work in progress. Those help stability, which is why they are often present, but the law itself is arithmetic over averages. ## Throughput is not capacity **Throughput is what did finish**, observed, under the real conditions of that window — including the interruptions, the blocked days and the rework. **Capacity is a claim about what could finish**, which is an inference, not a measurement. Treating an observed throughput of 2.4 items per day as a ceiling to be filled leads straight to committing to 36 items again next window and being surprised, because the conditions that produced 2.4 were not a policy decision. The distinction also protects the law itself: throughput is only a valid input while it describes completions, so a window where the team "finished" items by moving unresolved work to a parking column has a throughput figure that is fiction. ## What the law will not do - **It is not causal.** It states that three averages are related, not which one moves the others. It does not by itself prove that halving work in progress halves cycle time, though under stability that is the direction it points. - **It says nothing about an individual item.** An average cycle time of 7.5 days is no promise about the item a stakeholder is asking after. - **It does not forecast.** A single average is a poor basis for a date, because the underlying distribution is skewed. - **It does not survive a growing queue.** If work in progress climbed all window, the honest answer to "what is our cycle time?" is that the system is not stable enough for the question.

  • Why is throughput not a measure of the team's capacity?
    Throughput is observed: the completions that actually happened under that window's real conditions, interruptions and rework included. Capacity is an inference about a ceiling. Treating an observed 2.4 items per day as a target to fill assumes the conditions that produced it were chosen, when mostly they were not.
  • Half the items on the board have been abandoned rather than finished. What does that do to the law?
    It breaks conservation, the assumption that everything entering eventually leaves. Abandoned items inflate the work-in-progress count while contributing nothing to throughput, so the derived cycle time comes out far higher than measured reality. The disagreement between derived and measured cycle time is itself the signal that stale work is sitting on the board.
  • Does the law prove that adding people shortens cycle time?
    No. It states that three averages are related, not which one causes the others to move. Adding people often raises work in progress as well as throughput, leaving cycle time unchanged. Under stability the law points at reducing work in progress as the lever, but that is a direction to test rather than a proof.

saying these in an interview costs you the question

  • Applies the law to a single item's finish date
  • Uses it on a queue whose backlog keeps growing
  • Treats throughput as the team's maximum capacity
  • Mixes units, such as items per week against days
  • Measures work in progress and throughput at different boundaries