Little's Law in practice: why starting more work makes it slower
1. Before you start
A delivery queue has three numbers that move together. Work in progress (WIP) is how many
items are started but not yet finished. Throughput is how many items the team finishes per
unit of time. Lead time is how long one item takes to travel from “started” to “done.”
Little’s Law ties them in one line: on average, WIP = throughput × lead time — and,
rearranged, lead time = WIP ÷ throughput. A tiny example: if a team finishes 4 items a week
and holds 8 in progress, each item takes on average 8 ÷ 4 = 2 weeks to get through.
Three honest statements before you start:
- This is a Decide course. You read a situation, learn the idea, and make a call. You do not write or run any code.
- The companies below, Halyard Software and Northwind Support, are composite — invented teams built from ordinary figures so the arithmetic is clean. No number is a claim about any real company.
- This is not a certification. It proves, to you, that you can defend a flow decision.
You need only arithmetic. The hard part is a reflex you have to unlearn.
2. The Situation
Halyard Software’s product lead is furious that features take a month to ship, and her fix is to tell the team to start more work in parallel — “if everyone has more going at once, more will get done.” The delivery manager suspects the opposite is true but cannot say why. You have to settle it: does starting more work make delivery faster, or slower?
The trap is that “start more to go faster” feels obviously right and is exactly backwards — and one small law of queues tells you which lever actually moves lead time.
3. What you’ll be able to do
After this course you will be able to:
- Use Little’s Law to predict a queue’s lead time from its work in progress and its throughput, without a simulation or a guess.
- Show why piling on more WIP does not speed delivery — it lengthens lead time — so the reflex to “start more work” makes the very problem it is meant to fix worse.
- Compute the WIP cap a team must hold to hit a lead-time target, and name the one number that flips the call.
4. Prerequisites & time box
Prerequisites: arithmetic (multiply and divide). No queueing theory, no code, no spreadsheet. Helpful but not required: having seen a task board with a “doing” column.
Time box: about 17 minutes of reading (measured), plus your own thinking time on the call. That is under the 25-minute cap for a concept course.
Difficulty: 4 / 8 — a new-manager decision: a couple of interacting factors and one real judgment call, where the obvious answer is often the trap.
Free-tier honesty: no signup, no GPU, nothing to install — you read and decide in the browser.
5. The case & where the numbers come from
Halyard Software is a composite SaaS delivery team: its flow figures are built from ordinary numbers a small feature team would recognise, chosen for clean arithmetic and not drawn from or claimed about any real firm. The definitions — work in progress, throughput, lead time, and Little’s Law itself — are standard and cited in section 11. Every figure below is an in-course assumption; every later number is computed from these with the shown arithmetic.
| Item | Figure |
|---|---|
| Throughput (items the team finishes) | 5 items / week |
| Work in progress (items started, not yet done) | 20 items |
| Lead-time target the product org wants | 2 weeks or less |
| Team capacity (why throughput won’t just rise) | fixed in the short run — no hiring |
6. The Concepts
Work in progress
Work in progress (WIP) is the count of items that have been started but are not yet finished — everything sitting in the “doing” lane at once. Halyard has 20 features in progress. WIP is a stock: a snapshot of how much work is open right now, not a rate. It is the number the product lead wants to raise (“start more”), and it is the one that, as you will see, she should want to cut.
Throughput
Throughput is the rate at which the team finishes items — the flow out of the queue per unit time. Halyard finishes 5 items per week. Throughput is set by the team’s real capacity (how fast work actually gets completed), not by how much you start. Starting a sixth, tenth, or twentieth item does not make the team complete more per week; it just adds to WIP. In the short run — no new hires, same tools — throughput here is stuck near 5/week.
Lead time
Lead time is how long a single item takes to travel from “started” to “done” — the wait a customer or stakeholder actually feels. It is what the product lead is angry about. You do not need a stopwatch on every ticket to know it, because it is pinned by the other two numbers.
Little’s Law
Little’s Law says that, for a stable queue, the average work in progress equals the average throughput multiplied by the average lead time:
WIP = throughput × lead time
Rearranged, that gives the number Halyard cares about:
lead time = WIP ÷ throughput = 20 items ÷ 5 items per week = 4 weeks
So an average Halyard feature takes 4 weeks to ship — twice the 2-week target — and that falls straight out of holding 20 items open while finishing 5 a week. Nothing about the content of the work is in this formula; only the counts.
(An interactive calculator sits here — enter your own WIP, throughput, and lead-time target, and it returns the predicted lead time, the WIP cap that meets the target, and whether the current setup passes.)
Cutting WIP is the lever
Now test the product lead’s fix. She wants to start more — push WIP from 20 to, say, 30. Throughput is stuck at 5/week (no new people, same tools), so Little’s Law gives:
lead time = 30 ÷ 5 = 6 weeks
Starting more work made the wait longer, from 4 weeks to 6. The extra items do not get completed any faster; they just queue up, and every item now sits behind more work. Piling on WIP lengthens lead time — it never shortens it. That is the reflex to unlearn: “revenue is revenue” has a flow cousin, “starting is progress,” and both are wrong.
The lever that actually works is the opposite one — cut WIP. To hit the 2-week target while throughput stays at 5/week, rearrange the law for the WIP you are allowed to hold:
WIP cap = target lead time × throughput = 2 weeks × 5 items per week = 10 items
Cap the “doing” lane at 10 items and average lead time falls to 10 ÷ 5 = 2 weeks — on target — with the team finishing exactly as many features per week as before. Same throughput, half the WIP, half the wait. The only other way to cut lead time is to raise throughput (finish faster — smaller batches, automation, more people), but that is slow and often costs money; cutting WIP is free and immediate. The number that flips the call is WIP: it is the one lever the team fully controls today.
7. Your Call
You have seen how WIP, throughput, and lead time decide Halyard’s call. Now a different one lands on your desk.
Northwind Support runs a customer bug-and-request queue — a different company and a different kind of work from Halyard’s feature team. Its team clears 8 tickets a week and currently has 40 tickets actively in progress, against a customer promise (SLA) of a 2-week resolution time. There is an added wrinkle Halyard did not have: a hiring freeze, so throughput is capped at 8/week and cannot be bought up in the short run. The support manager’s instinct, under pressure, is to have everyone grab more open tickets in parallel to clear the backlog faster. Your job is to tell him what that does and what the queue must actually hold to meet the SLA.
How this differs from the taught case (the transfer): this is a different company (a support
desk, not Halyard’s feature team), the numbers are different so the arithmetic must be redone,
and there is an added constraint — a hiring freeze that pins throughput, so raising it is off the
table and the whole decision rests on WIP. The core concept is the same: Little’s Law
(lead time = WIP ÷ throughput) and the fact that more WIP lengthens lead time.
8. Self-check
Before you write the memo, make sure you can say each of these in one line:
- Why does starting more work make Northwind’s tickets resolve slower, not faster?
- Which single number decides the lead time when the team’s finishing rate is fixed?
- How do you turn a lead-time target into a hard cap on work in progress?
If any is fuzzy, reread section 6 — WIP, throughput, lead time, Little’s Law, and why cutting WIP is the lever are the whole course.
9. Stretch
Push the decision further on your own:
- Back at Halyard: the team’s throughput is not really fixed. If cutting WIP from 20 to 10 also removes context-switching and raises throughput to 6/week, what is the new lead time — and how much of the improvement came from less WIP versus faster flow?
- Northwind’s tickets are not all equal: 10 of the 40 are urgent, 30 routine. If you run two lanes with their own WIP caps, what target can you promise the urgent lane without breaking the routine one? (The genuinely harder one: Little’s Law holds per lane, so split throughput and solve each.)
- Write the one sentence you would say to a manager who insists “if everyone starts more, we’ll finish more.”
10. Ship it — your decision memo
Write a one-page memo to Northwind’s support manager. State the call (do not start more tickets; cap active WIP at 16 to hit the 2-week SLA, because at a fixed 8/week throughput lead time is WIP ÷ throughput). Show the two-line arithmetic (now: 40 ÷ 8 = 5 weeks; capped: 16 ÷ 8 = 2 weeks; the “start more” move: 60 ÷ 8 = 7.5 weeks). Name what you rejected (starting more work in parallel; waiting for headcount to raise throughput) and why. Name the one thing that would change your mind (a real, durable rise in throughput — smaller tickets, automation, or the freeze lifting). Keep it to a single page a manager grasps in two minutes. This memo is your own argued claim — not a credential.
11. Sources
Halyard Software and Northwind Support, and every figure attached to them, are composite — constructed for clean teaching arithmetic, not drawn from or claimed about any real company. The concept definitions used to reason about them are standard; references below.
| Concept / claim | Source (publisher) | URL | Accessed |
|---|---|---|---|
| Little’s Law: WIP = throughput × lead time | Wikipedia — Little’s law | https://en.wikipedia.org/wiki/Little%27s_law | 2026-07-20 |
| Definition of work in progress | Wikipedia — Work in process | https://en.wikipedia.org/wiki/Work_in_process | 2026-07-20 |
| Definition of throughput | Wikipedia — Throughput | https://en.wikipedia.org/wiki/Throughput | 2026-07-20 |
| Definition of lead time | Wikipedia — Lead time | https://en.wikipedia.org/wiki/Lead_time | 2026-07-20 |
| WIP limits in a delivery queue (kanban) | Wikipedia — Kanban | https://en.wikipedia.org/wiki/Kanban | 2026-07-20 |
Next up
Finished this call? Continue the Operations & Process track:
Make it or buy it: the unit-economics call, and the volume that flips it → · Browse all courses