What Is Work in Progress (WIP) — and Why Limiting It Speeds Everything Up
Work in progress (WIP) is the amount of work that has been started but not finished — every item currently somewhere between a workflow's trigger and its completion state. Limiting WIP means capping how many items may be in flight at once, so that finishing work takes priority over starting it. It is the most counterintuitive intervention in workflow management and, for most teams, the most effective: the same people, doing the same work, at the same pace, deliver noticeably faster when fewer things are open at the same time.
Nothing about that is motivational. It's arithmetic, and the arithmetic is worth understanding, because "start less to finish faster" sounds like a productivity slogan and is actually a property of how queues behave.
The Arithmetic
The relationship between how much work is in a system, how fast it flows through, and how long each item takes is stable and predictable: average delivery time rises in direct proportion to the number of items in progress, given a steady completion rate. Double the work in flight without adding capacity and each item takes roughly twice as long to come out the other end.
A concrete version. A team completes about five items a week. If ten items are in flight, an item entering the system waits behind roughly two weeks of work — so typical delivery is about two weeks. If the team keeps starting new items without finishing more, and thirty end up in flight, delivery stretches to about six weeks. Nobody slowed down. Throughput didn't change. The only thing that changed is how much was open at once, and delivery time tripled.
This is why the "we're all busy but nothing ships" complaint is so common and so resistant to effort-based fixes. High WIP produces exactly that experience: everyone genuinely occupied, everything genuinely progressing, nothing arriving.
Where the Extra Time Actually Goes
The arithmetic explains the queueing effect. Three additional mechanisms make high WIP worse than the math alone predicts.
Context switching. Each open item carries a cost to resume — recalling where it stood, what was decided, what's next. That cost is paid every time attention returns to it, so total switching overhead scales with how many items a person is holding. Work spread across eight open items consumes measurably more time than the same work done through four, then four more.
Waiting compounds at handoffs. When everyone downstream is also carrying too much, each handoff lands in a longer queue. High WIP in a multi-stage path doesn't add delay once — it adds it at every transfer, which is why cross-functional workflows degrade fastest under load.
Defects age. Problems found in work started three weeks ago are more expensive than problems found in work started three days ago: the context is cold, downstream work may already depend on it, and rework loops back through stages that have since filled with other items. High WIP means long feedback loops, and long feedback loops mean more expensive mistakes.
Why Teams Accumulate WIP Anyway
If limiting WIP is this effective, the natural question is why it isn't the default. The pressures are structural, not personal.
Starting is visible; finishing is not. Beginning work on a stakeholder's request produces immediate social relief — it's underway. The cost lands later and diffusely, on everything else in the queue.
Blocked work stays open. An item waiting on someone else's answer is still in progress. The rational individual response is to start something else, which is correct locally and, repeated across a team, is the primary mechanism by which WIP climbs.
Utilization gets mistaken for productivity. Idle capacity looks like waste, so slack gets filled with new starts. But queueing behavior is nonlinear — as utilization approaches full, wait times rise sharply rather than gradually — so the last increment of "efficiency" purchased is paid for many times over in delay.
Nobody owns the total. Individuals see their own load; nobody sees the sum. Without a visible count, WIP grows the way any unmeasured quantity grows.
How to Limit WIP
Count what's actually in flight, first. Most teams have never counted, and the number is usually higher than anyone's estimate — start-but-not-finished items scattered across boards, inboxes, and personal lists. Count once and the case for limiting usually makes itself.
Set the limit slightly below current levels, not at some ideal. If twenty-four items are in flight, cap at twenty, not eight. Aggressive limits get abandoned in the first busy week; modest limits get respected and can be tightened once the effect is visible. Limits work through adherence, not ambition.
Limit per stage, not just overall. A global cap allows everything to pile up at one stage. Per-stage limits make the constraint visible immediately: when the review column is full, upstream work must stop — which is uncomfortable and precisely the point, because it converts an invisible queue into a visible one that someone must address.
Decide in advance what happens when the limit is hit. This is the step teams skip, and it's what determines whether limits survive. The intended answer is that everyone helps clear the blocking stage rather than starting something new — "stop starting, start finishing" as an operating rule, not a poster. Without a pre-agreed response, hitting the limit just becomes an occasion to override it.
Exclude blocked work from the count, but make it visible. Items genuinely waiting on external input shouldn't consume a slot indefinitely, or limits become punitive. Move them to a blocked state with an owner and an age — visible, aging, and someone's responsibility to unblock. Otherwise "blocked" becomes an amnesty category and WIP re-accumulates under a different label.
What to Expect
The first two weeks under a limit feel worse. Work that used to be started immediately now waits at intake, and the delay is visible in a way that queue time never was — items sitting in a "not started" column look like inaction, even though the total wait is shorter. The instinct to override the limit peaks here.
What follows, if the limit holds, is a set of consistent effects: cycle times drop before throughput changes at all (items in the smaller pool finish faster); the actual constraint becomes obvious, because the stage that fills first is the bottleneck, now visible without any analysis; and finished work starts arriving in a steadier rhythm rather than in clumps at deadlines.
The honest caveat: WIP limits don't add capacity. If demand genuinely exceeds what the team can complete, limiting WIP makes that fact visible — work accumulating at intake instead of disappearing into a busy middle — but it doesn't solve it. That visibility is valuable and frequently unwelcome. It converts "the team is slow" into "we are asking for more than can be delivered," which is a harder conversation and a more accurate one.
FAQ
What does work in progress (WIP) mean in a workflow? Every item that has been started but not completed — all work currently between the workflow's trigger and its completion state, at any stage. It's usually counted per stage as well as in total, since where WIP accumulates identifies the constraint.
Why does limiting WIP make work faster? Because delivery time is proportional to how much work is in flight at a given completion rate. Fewer open items means each one waits behind less work and finishes sooner — with no change in effort or capacity. Reduced context switching, shorter handoff queues, and faster feedback add further gains beyond the arithmetic.
What is a good WIP limit? There's no universal number; the workable approach is to count current in-flight work and set the limit slightly below it, then tighten as the effect becomes visible. Limits set far below current levels tend to be abandoned during the first busy period, which costs more than a modest limit that holds.
Does limiting WIP reduce how much gets done? No — throughput is set by capacity, not by how many items are open. Limiting WIP changes when work completes, not how much. Teams typically see delivery times fall well before throughput changes at all, because the same completion rate is applied to a smaller pool of in-flight items.
What's the difference between WIP limits and prioritization? Prioritization decides what to start next; WIP limits decide how many things may be started at all. They complement each other — good prioritization with no limit still produces a large pool of half-finished high-priority work, which delivers slowly regardless of how well it was ordered.
