How to Calculate a WIP Cap

A WIP cap is a hard ceiling on how much work-in-process is allowed on the floor at once. You set it from Little's Law, target throughput times target lead time, so that releasing a new job requires an old one to finish. The floor then regulates itself: work cannot pile up faster than it clears, and lead time stops drifting because the queue can no longer grow without limit.

Most plants have no cap. Work is released on a schedule or whenever material shows up, the queues swell, and lead time becomes whatever the pile happens to be that week. A WIP cap replaces that with one number and one rule. This post shows how to calculate the cap from numbers you already track, how much buffer to add, and how to run it on the floor as a CONWIP loop, a constant-work-in-process system that keeps total jobs fixed.

What is a WIP cap?

A WIP cap is the maximum number of jobs, units, or containers permitted in a defined stretch of the process at any moment. Hit the cap and no new work is released until something exits. It converts inventory control from a daily argument into a property of the system, the same way a fixed number of kanban cards caps replenishment inventory. The difference is scope: kanban caps inventory per part number between two steps, while a CONWIP cap fixes total work across a whole loop, from a release gate to a finish line.

The cap is not a target you hope to stay under. It is a physical limit enforced by the release rule: one out, one in. That single rule is what makes the shorter, steadier lead time hold instead of eroding the first busy week.

Why cap work-in-process at all?

Because uncapped WIP makes a plant slower while it looks busier. By Little's Law, lead time equals WIP divided by throughput. If throughput is fixed by your constraint and you keep releasing work, WIP climbs and lead time climbs with it, you have manufactured delay, not output. The extra jobs sit in queues, aging, hiding quality problems, and tying up cash.

A cap breaks that loop. With total WIP fixed, throughput is still set by the constraint, so lead time holds steady and predictable. You also expose problems faster: when the cap is tight, a stopped machine backs up quickly and visibly, forcing a fix instead of letting the pile absorb it. That visibility is the point, not a side effect, it is the same logic as pulling a kanban card to surface the next constraint.

There is a cash argument too. Every job in the loop is material and labor you have paid for but cannot yet invoice, so a lower cap frees working capital directly. A plant that halves its WIP at the same throughput has, by Little's Law, halved its lead time and released half of that tied-up cash at once, without buying anything or laying anyone off.

How do you calculate a WIP cap?

Rearrange Little's Law. The law says WIP = throughput × lead time, so the cap that delivers your target lead time is simply your target throughput multiplied by that target lead time, plus a buffer for variability.

The steps, in order:

1. Define the loop. Name the exact start gate and finish line the cap governs. A cap on an undefined stretch is uncountable and unenforceable.
2. Measure current throughput. Use good units finished per day over a representative window, at the constraint. This is the rate the loop can actually sustain.
3. Set a target lead time. Decide what lead time the loop should deliver, usually shorter than today's. This is the number the cap is built to guarantee.
4. Multiply: base cap = throughput × target lead time. Keep the units consistent (units and days, or jobs and hours). This is the raw ceiling.
5. Add a variability buffer. Real lines have arrival and processing variation, so add 10–30% depending on how choppy the flow is. Steadier lines need less.
6. Round to a countable unit. Express the cap in whatever the floor can see at a glance, jobs, totes, or slots on a board, so anyone can tell when it is full.
7. Publish the one-out-one-in rule. The number does nothing without the release rule beside it. Post both where work is released.

How much buffer should you add?

Enough to keep the constraint fed, no more. The buffer exists because arrivals and processing times vary; without it, normal variation would starve the constraint whenever the loop briefly ran light. Choppier flows, high mix, unreliable equipment, unstable demand, need more, toward 30%. Steady, repetitive lines need less, toward 10%. When you cannot decide, start higher and tighten, because a too-tight cap that starves the constraint costs real output, while a slightly loose cap only costs a little extra lead time.

This is also where a WIP cap and a constraint buffer meet. The cap fixes total work in the loop; the buffer is the deliberate slice of that work you keep in front of the slow step so it never idles. Sizing the two together is the practical core of managing flow, and it is why the cap is a starting point to tune, not a permanent constant.

What is CONWIP, and how is it different from kanban?

CONWIP, constant work-in-process, is a WIP cap applied to a whole loop rather than to each part between two steps. One signal governs the entire stretch: when any job exits the finish line, one new job may enter at the release gate, whatever part it is. Kanban, by contrast, runs many small capped loops, one per part number between adjacent steps.

The practical trade: CONWIP is simpler to run and better for high-mix work, because it does not need a card loop for every part; kanban gives tighter local control and works best where parts and volumes are stable. Many plants run CONWIP for the overall release discipline and kanban inside it for specific repetitive components. Both rest on the same idea, a fixed count that makes overproduction physically impossible.

What happens when you hit the cap?

Nothing new starts, and that is the system working, not failing. A full cap is a signal: the loop already holds all the work it can carry at the target lead time, so adding more would only lengthen queues. The right response is to help finish something, not to override the gate. When teams start overriding the cap "just this once," they have quietly gone back to uncapped WIP and the lead time gains dissolve.

A full cap also points a spotlight. If work keeps backing up to the gate, the loop cannot sustain the throughput you assumed, usually the constraint is losing time. That turns the cap into a diagnostic: it tells you to go work the constraint's losses, which is exactly the conversation an OEE calculation at that machine is built to inform.

By the numbers

The math behind the cap is not a heuristic; it is a proven law. Little's Law, average number in system equals arrival rate times average time in system, was proved by John D. C. Little in 1961 in "A Proof for the Queuing Formula: L = λW," Operations Research 9(3):383–387 and it holds without assuming any particular distribution of arrivals or service times, which is why it applies to a job shop as readily as a queue at a bank. The scale of uncapped inventory is national: U.S. manufacturers carried an inventories-to-shipments ratio of 1.47 in May 2026, per the U.S. Census Bureau's M3 report about a month and a half of shipments held as stock. A cap is how a single plant stops contributing to that pile.

How do you run and tune a WIP cap?

Make the count visible and the rule automatic, then adjust from data. A slot board, a fixed number of job folders, or a digital limit all work, as long as anyone can see at a glance whether the loop is full. Tie the release to the exit, one out, one in, so the discipline does not depend on a person remembering it. Then tune: if lead time is steady and the constraint never starves, tighten the cap a notch and watch; if the constraint idles, loosen it. Fold WIP level and lead time into your manufacturing KPIs so the cap's effect is tracked, not assumed.

All of this depends on knowing the real count and the real exit rate, which is where paper falls short. Plants like CLS replaced paper production logging with real-time capture, so the WIP count and completion signal are live rather than reconstructed at shift end. For the broader set of measures that tell you whether the cap is working, see WIP metrics and work-in-process reduction; to size the constraint losses that determine how tight a cap you can hold, start with a free OEE calculator.