Work In Progress Limits In Practice

The argument for limiting work in progress is settled. It follows from Little's Law, it is visible in the cycle time data of every team that has ever tried it, and it is the one intervention in delivery management that costs nothing and can be undone in an afternoon. If you need convincing on the theory, the queueing argument is laid out elsewhere.

What is not settled is the practice. Most teams that claim to have WIP limits have a number written above a column on a board that nobody enforces, chosen by consensus at a workshop eighteen months ago, and quietly exceeded every week without comment. That is not a WIP limit. That is a decoration.

A WIP limit is a rule that changes behaviour at the moment it binds. If it has never stopped anyone doing what they wanted to do, it is set too high and you have learned nothing. The entire value of the mechanism lies in the awkward conversation it forces: we cannot start this, so what are we going to do instead? Everything below is about making that moment productive rather than merely irritating.

Per-state, per-person, per-team

There are three places you can attach a limit, and they do different jobs.

Per-team limits cap the total items in flight across the whole board. Simple to explain, trivially easy to game by splitting work into more items, and useful only as a blunt first instrument. They tell you nothing about where the problem is.

Per-person limits cap how many items any individual may own at once. The usual number is one, occasionally two. These are the most emotionally contested and the most immediately effective, because the dominant failure mode in knowledge work is not team overload but individual multitasking — the developer with four branches open, the designer holding six half-finished flows. Context switching has a fixed cost per switch that nobody accounts for and everybody pays.

Per-state limits cap the number of items sitting in a given column. These are the ones that actually teach you something, because when a column fills up, the board is telling you precisely where the system is constrained. A per-state limit converts a vague sense that things are slow into a specific, located, arguable fact.

Use per-state limits as your primary mechanism. Add a per-person rule underneath if individual multitasking is visibly the problem. Use a per-team cap only as a temporary blunt instrument, and retire it once per-state limits are holding.

Where to put the limit

Here is the part that almost everyone gets wrong. Teams tend to set a limit on every column, uniformly, usually derived from team size. Three developers, so the limit on In Progress is three. Two reviewers, so the limit on Review is two. This is resource-efficiency thinking wearing flow-efficiency clothes, and it will not help you.

The limit belongs at the constraint, and immediately upstream of it.

Find the constraint first. Walk the board and ask, for each state, how long items sit there. Not how long they take to work on — how long they sit. The state with the longest wait time is your constraint, and it is very rarely the development column. In most organisations it is code review, environment availability, a security or architecture approval, or a downstream team's queue.

Once you have located it, two limits matter:

• A limit on the constraint state itself, set to roughly what the constraint can actually process concurrently without thrashing. This protects it from being buried.
• A tight limit on the state immediately upstream, which is what stops work piling up in front of the constraint. This is the one that creates the useful pressure, because it makes upstream people stop and notice that the bottleneck exists.

Everything else on the board can go unlimited at first. Limits on states that are not constraining anything just generate noise and erode people's willingness to respect the limits that matter.

Choosing the number

There is no formula, and anybody selling you one is selling you a formula. There is, however, a reliable procedure.

Start from where you are. Count the items currently in flight in the target state, averaged over the last few weeks. Set the limit at roughly two-thirds of that. Hold it for three to four weeks. Measure cycle time percentiles before and after — not averages, percentiles, because the distribution is the point.

Then tighten again. Keep tightening until one of two things happens: cycle time stops improving, or throughput starts falling. Both are signals that you have found the floor. Back off one notch and stay there.

This ratchet beats any up-front calculation because it works with the system you actually have rather than the one on the org chart. It also gives people a cadence — a limit that changes every few weeks is understood as a dial being tuned, not a judgement being imposed.

Two practical bounds. Below a limit of about two on a shared state, you will get stalls from ordinary variability alone. Above roughly one and a half items per person working in that state, you are not limiting anything.

What happens when the limit is hit

This is the whole mechanism, and it needs to be agreed in advance, in writing, before it happens. Otherwise the first time the limit binds, someone senior will simply override it and the limit will be dead.

The rule is: when you cannot pull, you help.

In practice that resolves into an ordered list, and the order matters.

First, unblock something. Look right, not left. Is there an item in a later state that is stuck? Unblocking a downstream item creates a pull that frees the whole chain. This is almost always the highest-value action available and almost never the first one people think of.

Second, swarm the nearest item to done. Pair on it, review it, test it, write its documentation, chase its approval. Finishing something is worth more than starting something, always, because value is realised at done and nowhere else.

Third, do improvement work. Not new feature work — improvement work aimed at the constraint. Automate a step in the release path, clean up a flaky test, build the environment tooling that keeps causing waits. Slack directed at the bottleneck compounds.

Fourth, and only fourth, find out what is coming. Refinement, discovery, spikes. Useful, but it is the option that most resembles starting new work and most likely to degrade into it.

Never: start the next item anyway. If this happens twice without challenge, you no longer have a WIP limit.

Pull rules and blocker escalation

A WIP limit only functions inside a pull system. Push and limits are incompatible: if work is assigned into a state by someone outside the team, the limit is not a limit, it is a suggestion the assigner can ignore.

So write the pull rules down. Who may move an item into each state, and on what condition. The condition is usually an explicit entry criterion — a definition of ready for that column, which is a narrower and far more useful thing than a global definition of done. "An item may enter Review when it has a green build and a description of what a reviewer should look at." That sentence removes a whole category of wasted review cycles.

Blockers need their own treatment, because a blocked item occupying a limited state is the worst of both worlds: it consumes the limit and produces nothing.

Adopt an explicit escalation ladder with times attached, and make the times short enough to feel aggressive:

Blocked for	Who acts	What they do
Same day	The team	Swarm it, or find a workaround within the team's control
One day	Team lead or Scrum Master	Named owner outside the team contacted directly, not via ticket
Two days	Accountable manager	The blocking party's manager is involved; a date is agreed
Three days	Delivery leadership	Treated as a systemic issue, logged as a recurring impediment

The important design choice is that the clock is measured in days, not sprints. Teams that escalate at sprint boundaries have already lost a week. The second design choice is that blockers are counted and reviewed as a class, monthly. A single blocker is an incident. The same blocker appearing eleven times is an architecture or organisational-design problem wearing a disguise, and it will usually turn out to be a dependency that no amount of team-level discipline can fix.

The political conversations

You will have three, and they are predictable enough to prepare for.

"This will leave people idle." It might, occasionally, briefly. Your answer is that idle people are visible and cheap, whereas queued work is invisible and expensive, and that the organisation is already paying for the second at a far worse rate. Bring the flow efficiency number. If touch time is fifteen percent of elapsed time, the organisation is not suffering from a shortage of activity.

"My thing is urgent, start it now." This is the real test, and it usually arrives from someone with more authority than you. The answer is not refusal, it is a trade: something currently in flight must be stopped and moved out, explicitly, by name, with the consequences owned by the person asking. A WIP limit does not prevent urgent work. It prevents unacknowledged urgent work. Once stopping named items becomes the visible price of interruption, the volume of urgent requests falls sharply, which tells you something about how urgent they were.

"We need an expedite lane." Allow exactly one expedite slot, standing, organisation-wide if you can manage it. One item, at a time, across the team. The moment there are two expedite lanes, nothing is expedited and you have rebuilt the unlimited board with extra steps.

The meta-conversation underneath all three is about who is permitted to say no. WIP limits do not create that authority question; they surface it. If nobody in the delivery organisation can decline to start work, the limits will not survive, and the problem you actually need to solve is upstream of the board — in how demand is prioritised and how middle management understands its role.

Telling whether it is working

Four signals, checked weekly. None of them is "the limit is being respected", which measures compliance rather than effect.

Cycle time percentiles are falling. Specifically the eighty-fifth, which is the number you can promise against. If the median falls but the tail does not, you have sped up the easy items and left the hard ones queueing — usually a sign the limit is in the wrong place.

Throughput is flat or rising. Falling throughput alongside falling cycle time means the limit is too tight and the system is starving. This is rare but real.

Flow efficiency is rising. Touch time over elapsed time. If it is not moving, the waiting has relocated rather than reduced, which usually means you limited a non-constraint.

Blocker count and blocker age are visible and being argued about. A team that has started complaining loudly about specific external dependencies is a team whose WIP limit is working. Silence is the warning sign, not the noise.

If none of these move after four weeks, the most likely explanation is that the limit is above your natural operating level and has never bound. Tighten it and try again.

What to do on Monday

Open the board. For each column, work out the median time items spend sitting in it. If your tool will not tell you, sample fifteen recently completed items by hand — it takes an hour and the result will be more convincing than anything automated, because you will have seen it.

Name the worst column out loud. That is your constraint until proven otherwise.

Set two numbers: a limit on that column at roughly two-thirds of its current average occupancy, and a tighter one on the column immediately before it. Leave every other column unlimited for now.

Write the pull rule and the "when you cannot pull, you help" ladder on the same board, in the same place, where people stand for the daily. Agree the blocker escalation times with whoever will be escalated to, before you need them.

Then hold it for four weeks without renegotiating, and put the cycle time distribution from the four weeks before next to the four weeks after in the same chart. That comparison is the only argument you will need for the next tightening.