Little's Law and WIP Limits
12 min · Flow and Continuous Improvement
When throughput is steady, more work in progress means more waiting. A deterministic simulation lets you compare a crowded system with a constrained one without treating the model as a production forecast.
Video
core01 / 05
A busy coffee shop is a queue
02 / 05
Little’s Law connects stock, rate and time
| Work in progress | At 10 orders/h |
|---|---|
| 20 customers | 20 ÷ 10 = 2 hours |
| Cap: 10 customers | 10 ÷ 10 = 1 hour |
| Crowd: 40 customers | 40 ÷ 10 = 4 hours |
03 / 05
Starting more adds waiting
04 / 05
A WIP limit creates a pull decision
05 / 05
Stop starting, start finishing
Playback settings
Resume playback at ?
Player ready. Captions are on by default.
Full lesson transcript: Little's Law, WIP limits and FlowSim
Walk into a coffee shop with twenty people inside and two baristas working flat out. Now answer fast: will you get your coffee sooner if more customers crowd in? Of course not — and congratulations, you already understand a sixty-year-old theorem of queueing mathematics. You've just never applied it to your own to-do list. Today that changes.
By the end of this video, you'll be able to predict what happens to waiting time when work-in-progress changes, explain why WIP limits are the single highest-leverage move in this entire course — and you'll have a four-word mantra you will never unlearn.
In 1961, John Little proved a relationship so general it holds for coffee shops, hospitals, factories, and your inbox. In plain terms: lead time equals WIP divided by throughput. How long things take equals how many things are in the system divided by how fast things finish.
Let's run the coffee shop with real numbers. Twenty customers inside; the baristas complete ten orders an hour. Twenty divided by ten: the average customer spends two hours in that shop. Now the manager caps entry at ten customers — same two baristas, same espresso machine, same skill. Ten divided by ten: one hour. Waiting time halved, and nobody worked faster, hired anyone, or bought equipment. The only thing that changed was how much was in progress at once.
That's the whole law, and notice its cruel symmetry: it works in reverse. Let the crowd double and every single customer waits twice as long — including the ones who were already there.
Translate. Every time a team says yes to one more "in progress" item without finishing one first, it silently lengthens the wait for everything already started. Starting feels generous — look how responsive we are! Mathematically, it's the opposite: each new start is a small tax on every unfinished thing. Last lesson's support team, with eleven items in progress and twenty-eight-day lead times? That wasn't a work-ethic problem. It was arithmetic.
And there's a hidden second tax the equation doesn't even show: context-switching. Humans reload slowly. Every jump between tasks burns time on remembering where you were — so high personal WIP doesn't just divide your attention, it shrinks your real throughput too. The equation gets worse in practice than on paper.
Don't take my word for any of this. Run the experiment on yourself this week: pick your five open tasks, and finish them two-at-a-time-maximum instead of all-at-once. Feel what happens to your delivery dates. Better yet — the simulator below this video lets you feel it in ninety seconds.
If lead time equals WIP divided by throughput, and throughput is roughly fixed by your capacity, then WIP is the one lever you control today. A WIP limit is a deliberate cap on concurrent work: "no more than three items in Doing." Simple, visible, brutal — and it transforms behavior, because when the limit is reached, you cannot start. You must finish something first.
That flips the system from push to pull. Push: work is shoved onto people whenever it arrives, regardless of load. Pull: new work enters only when capacity genuinely frees up. The limit is what creates the pull.
And when the limit blocks you and your hands are free? You swarm: go help finish something already in progress. Review a colleague's draft, unblock the stuck item, pair on the hard part. Idle-by-the-limit is not idle — it's the system telling you where your effort actually shortens the queue.
Say the mantra with me, because it compresses this entire lesson into four words: stop starting, start finishing.
You might think starting more things means finishing more things — it's the most natural belief in the working world, and entire careers are built on looking loaded. That's understandable: starting is visible, instant, and feels like progress. Actually, Little's Law says starting more slows everything down while finishing nothing sooner — and context-switching makes it worse than the math. The team that looks slightly under-loaded and finishes relentlessly isn't lazy. It's literate.
Three things to keep. One: lead time equals WIP divided by throughput — more in progress at once means everything takes longer, coffee shops and teams alike. Two: WIP limits are the lever — they force finishing and create pull instead of push; when blocked, swarm. Three: stop starting, start finishing.
Limits need somewhere to live, and they live on a board. But a board is more than three columns and some sticky notes — done right, a board thinks: it confesses where work waits and points at the bottleneck. Next lesson, we make the board honest.
The approved narration and storyboard are present in the source pack. The text digest and deterministic simulator provide reviewable non-video paths.
References
Reading
coreLittle’s Law and WIP limits
For a stable system, Little’s Law gives a useful relationship: average lead time = average work in progress ÷ average throughput. It is a long-run relationship, not a promise about one item.
Imagine a coffee shop with twenty customers inside and a steady throughput of ten customers served each hour. The average experience is two hours. If the same baristas keep the same throughput while only ten customers are admitted into the system, the average falls toward one hour. More started work did not create more finishing capacity; it created waiting.
A WIP limit is an agreement not to start another item when a stage is full. It can feel like imposed idleness, but the visible spare capacity is a signal to help finish blocked or queued work. “Stop starting; start finishing” is a system rule, not a demand for individuals to remain busy.
The relationship depends on a reasonably stable boundary and period. Arrival spikes, changing capacity, different item sizes, and blocked work all affect observed results. Use the law to reason about direction and system design, then inspect real data rather than treating the equation as a precise forecast.
Admitting fewer customers can move the queue outside the shop. The shorter average inside does not establish a shorter end-to-end wait or greater capacity. Measure waiting before admission as well, and preserve an accessible, safe route for people who cannot wait. A WIP limit should improve the whole service rather than hide unfinished demand beyond its counting boundary.
The accompanying simulation compares the same work and capacity under two WIP conditions. It is deterministic so the learning path is reproducible; it is not a production model.
References
Interaction
corePractice · flow simulator
The Flow Sim
Advance the deterministic model and watch work wait at constrained stages. Use the trace with the digest to compare crowded and WIP-limited policies.
Concepts: work in progress, lead time, throughput
Deterministic run · seed 402
Step 0 of 10
Step 0: 3 items in progress, 0 waiting, and 0 completed this step.
Ready
Capacity: 3
- Request Alpha — active, 1 work remaining
- Request Gamma — active, 1 work remaining
- Request Beta — active, 1 work remaining
Doing
Capacity: 2
Review
Capacity: 1
Release
Capacity: 1
Done
Capacity: 3
Activity ready. Attempts are unlimited. Completing this practice activity enables the lesson's separate, explicit completion control.
Equivalent non-interactive path
Narrated step-through using the same deterministic run
The walkthrough below uses seed 402, the same stages, arrivals, capacities, and results as the interactive controls.
- Step 0: 3 items in progress, 0 waiting, and 0 completed this step.
- Ready: Request Alpha (active), Request Gamma (active), Request Beta (active)
- Doing: empty
- Review: empty
- Release: empty
- Done: empty
- Step 1: 4 items in progress, 1 waiting, and 0 completed this step.
- Ready: Request Delta (active)
- Doing: Request Alpha (active), Request Gamma (active), Request Beta (waiting)
- Review: empty
- Release: empty
- Done: empty
- Step 2: 5 items in progress, 2 waiting, and 0 completed this step.
- Ready: Request Epsilon (active)
- Doing: Request Alpha (active), Request Gamma (active), Request Beta (waiting), Request Delta (waiting)
- Review: empty
- Release: empty
- Done: empty
- Step 3: 6 items in progress, 2 waiting, and 0 completed this step.
- Ready: Request Zeta (active)
- Doing: Request Beta (active), Request Delta (waiting), Request Epsilon (active)
- Review: Request Alpha (active), Request Gamma (waiting)
- Release: empty
- Done: empty
- Step 4: 6 items in progress, 3 waiting, and 0 completed this step.
- Ready: empty
- Doing: Request Delta (active), Request Epsilon (active), Request Zeta (waiting)
- Review: Request Alpha (waiting), Request Gamma (active), Request Beta (waiting)
- Release: empty
- Done: empty
- Step 5: 6 items in progress, 3 waiting, and 0 completed this step.
- Ready: empty
- Doing: Request Zeta (active)
- Review: Request Alpha (waiting), Request Beta (waiting), Request Delta (active), Request Epsilon (waiting)
- Release: Request Gamma (active)
- Done: empty
- Step 6: 6 items in progress, 4 waiting, and 0 completed this step.
- Ready: empty
- Doing: empty
- Review: Request Alpha (waiting), Request Beta (waiting), Request Delta (waiting), Request Epsilon (waiting), Request Zeta (active)
- Release: empty
- Done: Request Gamma (active)
- Step 7: 5 items in progress, 4 waiting, and 1 completed this step.
- Ready: empty
- Doing: empty
- Review: Request Alpha (waiting), Request Beta (waiting), Request Delta (waiting), Request Epsilon (active), Request Zeta (waiting)
- Release: empty
- Done: empty
- Step 8: 5 items in progress, 3 waiting, and 0 completed this step.
- Ready: empty
- Doing: empty
- Review: Request Alpha (waiting), Request Beta (waiting), Request Delta (active), Request Zeta (waiting)
- Release: Request Epsilon (active)
- Done: empty
- Step 9: 5 items in progress, 2 waiting, and 0 completed this step.
- Ready: empty
- Doing: empty
- Review: Request Alpha (waiting), Request Beta (waiting), Request Zeta (active)
- Release: Request Delta (active)
- Done: Request Epsilon (active)
- Step 10: 4 items in progress, 1 waiting, and 1 completed this step.
- Ready: empty
- Doing: empty
- Review: Request Alpha (active), Request Beta (waiting)
- Release: Request Zeta (active)
- Done: Request Delta (active)
When arrivals exceed stage capacity, items wait. Limiting active work makes that queue visible and preserves the same relationship in both modes.
References
Sign in to save progress across devices.Sign in
Course outlineLesson 20 of 28
Orientation
The Agile Mindset
Teams, Roles and Rhythm
Delivering Value
Flow and Continuous Improvement
Agile in the Real World