What it is and why it matters
WIP (work in progress) is the number of items that have started and not yet finished. The WIP limit is an explicit ceiling on that number, set per step, per group of steps or for the whole system. It is the practice that turns a board into a pull system: a new item only enters when another one leaves.
The reason to limit is simple to state and hard to accept at first: the more items in parallel, the longer each one takes and the later problems surface. Teams that start everything at once look busy and deliver little.
Key concepts
How to set the first limit
There is no exact formula. A practical starting point is to observe the WIP of each step for two weeks and set a limit slightly below the average. Another reference is the number of people in the step: far below it, people are left without an item; far above it, each person piles up several. The right limit is found by adjustment, watching delivery time and pace.
What to do when a step reaches its limit
Reaching the limit is a signal, not a failure. The practical rule is stop starting and start finishing. Before pulling something new, the available person looks for a way to help finish what is already in the system: unblock an item, help the next step that is full, review a colleague’s work, pair on an old item. Breaking the limit should be an exception foreseen in a policy, such as the expedite lane, and not a decision made on the spot.
Multitasking
Each extra item in parallel carries a context switching cost: picking up the line of thought again, reopening tools, remembering where you stopped. And multitasking delays all items at the same time. With three 5-day items alternated daily, the first one is only done on day 13; done one at a time, they finish on days 5, 10 and 15. The total time is similar, but value and feedback arrive sooner.
Bottleneck
The bottleneck is the step with the lowest capacity relative to demand. It sets the pace of the whole system: working faster before it only grows the queue in front of it. The typical signs are a growing queue right before the step and idle downstream steps.
The theory of constraints, by Eliyahu Goldratt, proposes a useful sequence: identify the bottleneck, exploit it fully (no lost time, no rework entering it), subordinate the rest of the system to its pace, elevate its capacity and repeat, because the bottleneck moves. WIP limits are the most direct way to subordinate: they keep upstream steps from producing more than the bottleneck can absorb. Try this in the bottleneck experience.
Utilization and queues
A common intuition is that a team should be 100% busy. Queuing theory shows the opposite. In a simple queue model, waiting time grows nonlinearly with utilization: at 80%, the average wait is about four times the service time; at 90%, about nine times; at 95%, about nineteen. With the variability typical of knowledge work, the effect is usually even worse. Spare capacity is not waste: it is what absorbs urgent requests and variation without delivery times blowing up. The variability and queues challenge shows this effect with numbers.
Little’s Law
Little’s Law relates three averages of a stable system:
Average cycle time = Average WIP ÷ Average throughput
If a team has on average 12 items in progress and delivers on average 3 items per week, the average cycle time is around 4 weeks. Reducing average WIP to 6, at the same delivery pace, brings the average time to about 2 weeks.
The law holds under assumptions the exam tests:
- the three metrics use consistent units and the same period;
- the average arrival rate equals the average departure rate;
- every item that enters eventually leaves, either finished or explicitly discarded;
- WIP at the start and at the end of the period is roughly the same;
- the average age of items in progress is neither increasing nor decreasing.
When these assumptions are violated, the formula no longer describes the system. The law helps you understand the effect of WIP and assess flow stability, not predict when a specific item will finish: for that, use the probabilistic forecasting from domain 4.
Aging
Work Item Age is the time elapsed since the start of an item that has not yet finished. Among the flow metrics, it is the one that looks at the present: cycle time and throughput talk about items that have already left. The aging chart shows each item in progress in its step, with its age, next to the historical cycle time percentiles. An item that is 11 days old in a step where 85% of items finish by day 8 deserves a conversation today, before it turns into a delay.
Common mistakes
- A limit so high it is never reached. It changes no behavior at all.
- Raising the limit every time it is reached. The limit exists to reveal the problem; raising the limit hides it.
- Using Little’s Law to promise dates. It deals with averages of a stable system, not with individual items.
How this shows up on the exam
You will find situations such as: the testing step is at its limit and a developer has finished their item; what is the best action? Or WIP and throughput data, with a question about the effect of a change. Some questions describe an unstable system, with WIP growing over the period, and ask whether Little’s Law applies. You will also see aging charts and have to decide which item needs attention first.
Frequently asked questions
What is the ideal WIP limit for a team?
There is no universal number. Start slightly below the current WIP, watch delivery time and exit rate, and adjust. If there is never tension at the limit, it is too high; if people sit idle and cannot help, it may be too low.
Doesn’t limiting WIP leave people idle?
Sometimes it does, and that is useful information. Whoever has no item to pull helps finish what is already in the system. Recurring idleness in a step points to a capacity imbalance, which the limit has only made visible.
Can Little’s Law predict delivery dates?
Not for individual items. It relates averages of a stable system and helps you understand the impact of WIP on time. For delivery dates, use cycle time percentiles and probabilistic forecasting, such as Monte Carlo simulation.
