WIP Limits: Start Less, Finish More

TL;DR: Everything your team has started is either moving or waiting, and the more you start, the more everything waits. A WIP limit is a cap on simultaneously open work that converts "we're busy" into "we're finishing." The math is queue theory, the psychology is context switching (in a study of 10,000+ programming sessions, only ~10% of resumed sessions got back to editing code within a minute), and the practice is one rule: when the limit is hit, help finish something instead of starting something. Limits won't fix a review bottleneck or a dependency mess, but they'll make both impossible to ignore, which is the step before fixing them.

Walk any team's board and count the cards in flight. Now count the people. If the first number is a multiple of the second, you've found the reason "everything takes forever," and it isn't that anyone is slow. Everything is waiting, and waiting compounds while nobody's looking.

What are WIP limits?

A work-in-progress limit is exactly what it sounds like: a maximum number of items allowed in a state - "in progress: 4," "in review: 3" - enforced by one behavioral rule. When the column is full, you don't start new work; you help finish existing work. Pick up a review, unblock a teammate, pair on the stuck thing. Stop starting, start finishing.

That's the whole mechanism. It looks almost insultingly simple, which is why teams skip it in favor of tooling, reorgs, and hiring: three expensive ways to avoid admitting that the problem is arithmetic.

Why work in progress makes everything late

Two forces, one from math and one from meat.

The queue math. For a stable system, the average time an item spends in the system is proportional to the number of items in it, divided by the rate at which items finish. (This is Little's law: a theorem, not a management opinion.) The consequence is brutal: if your team finishes work at a fixed rate, doubling the amount of started work doubles the average wait for everything, including the urgent thing you started last Tuesday precisely because it was urgent. Starting work does not make it arrive sooner. Finishing work does. Everything else is inventory.

The context-switching tax. Every parallel item a person carries is a future interruption. Parnin & Rugaber's study of 10,000+ programming sessions across 86 programmers found that after an interruption, only about 10% of sessions resumed editing code within a minute, and roughly 30% took more than 30 minutes to get back to it. Multiply that resumption cost by every hop between your three open tickets, two review requests, and the incident channel, and "80% utilized on four things" reveals itself as much less than one person's worth of actual progress.

The waiting isn't hypothetical either; it shows up in the delivery telemetry. LinearB's benchmarks across 8.1M+ PRs band PR pickup time from under an hour (elite) to over 16 hours (needs focus): the same finished code, sitting motionless, purely because the people who should review it are busy starting things. High WIP is how a team's PRs get stuck in review while everyone is simultaneously slammed and blocked.

How to set WIP limits without theater

There is no researched magic number, and this article won't invent one (a number without a source is a decoration). The honest procedure:

1. Count your current WIP. All of it: in progress, in review, blocked, "quick thing for sales." The first count is usually a shock, and the shock is the point.
2. Set the initial limit just below reality. Current WIP minus one or two. A limit that requires no behavior change is a poster; a limit that requires a revolution gets ignored. You want the smallest number that forces one real finish-first decision per day.
3. Limit the queues, not just the work. "In review" and "waiting for deploy" columns need limits more than "in progress" does. Queues are where time actually dies, as the cycle-time stage breakdown shows.
4. Make blocked work loud. A blocked item inside the limit is spending your capacity. Flag it, count its age, and treat unblocking as work - because it is.
5. Tighten gradually, watching two numbers. If cycle time falls while throughput holds, tighten again. If throughput falls, you've gone too far or you've hit a real constraint, which is exactly what the limit was for. Let the data decide.

A common starting policy is one to two active items per person, stated plainly as a heuristic that encodes "humans don't parallelize," not as a research finding.

What WIP limits surface (and what they won't fix)

The part the kanban evangelists undersell: a WIP limit doesn't fix your bottleneck. It finds it, then makes it everyone's problem in the most productive way possible.

Cap "in review" at three, and within a week you'll know exactly who the review load actually lands on and how long pickup really takes. Cap "in progress," and the dependency on the one platform team - or the one person who understands the deployment pipeline - stops hiding behind a wall of parallel busyness. The limit converts diffuse slowness into a specific, nameable queue with a specific, nameable cause. That is the product.

What limits won't do: they won't review PRs for you, staff the bottleneck, or negotiate with stakeholders who want everything started now as proof of caring. Starting work is how organizations perform commitment; finishing work is how they deliver it. Expect that argument, and bring the receipts. The DORA research has spent a decade showing that the fast-and-stable teams are the ones working in small batches with fast feedback, and small batches are precisely what a WIP limit enforces at the system level, the same way small PRs enforce it at the change level.

Start less. Finish more. Watch the flow numbers move, and when they do, it won't be because anyone worked harder. It'll be because the work finally stopped standing in line behind itself. The full scoreboard this feeds lives in the delivery-metrics hub.