Work in Progress Limit

Holding several items at once looks like a great deal of work getting done. When everybody reports three things in progress, the picture that emerges is of a team running hard.

Pagedeck's engineering team was in exactly that state. Five people each had two or three items open, so twelve cards were sitting in progress at once. Even working through weekends, three cards a week were reaching the done column. Each of the cards was 80 or 90 percent of the way there, and exactly three were finished.

The core of the problem is that started work is worth zero until it finishes. A feature that is 90 percent built gives a user nothing at all. On top of that, time leaks out while somebody moves between items — every switch means recalling where they left off, and that loss is called context switching.

A work in progress (WIP) limit is a rule against starting. Under kanban, which makes the flow of work visible and limits work in progress to improve that flow, it belongs to the rule group, the one that decides what's forbidden on the board.

Five steps are what put it in place.

1. Write a number on each column. Next to the column titles of a kanban board, where cards sit in state columns, record things like In progress 3, Code review 2.
2. Don't pull a new card once the cap is reached. With three cards in the in-progress column, a fourth can't be opened even by somebody whose hands are free.
3. Push an existing card along instead. When the review column is blocked, an engineer reviews rather than starting something new. That switch is the one behavior this rule actually produces.
4. Start below headcount. With five engineers on the team, set the in-progress column to three or four. Set it equal to headcount and the state where everybody holds one item and nobody helps anybody else is permitted exactly as it already was.
5. Run it a few weeks and adjust. Raise it by one if hands are often idle; lower it by one if cards linger in a column.

Two separate things make the rule work. One is arithmetic: the average time one card takes equals the number of items in progress divided by throughput. With twelve items in progress and three finished a week, one card averages four weeks. Cut in-progress to six and the same team gets two weeks. The waiting time was halved without anybody having to work faster. The other is the reduction in the switching loss described above.

Exposing a hidden bottleneck matters just as much. Without a cap, cards simply pile up in front of a blocked column while the people upstream keep starting new work of their own. With a cap, the upstream column stops too, so everybody learns on the same day where the bottleneck is — the slowest stretch that alone sets the overall pace. That is how a fact like one person doing all of the reviews comes out into the open.

A kanban board is the default home for this. Teams working in fixed cycles can put the same rule on a board, because deciding which items go in is a separate question from deciding how many get opened at once.

It also gets applied per horizontal lane. When incident response and new features compete for the same column, the urgent one always wins. Split the lanes and cap incidents at two and features at three, and urgent work stops swallowing everything else.

Confirming the effect happens through metrics: cycle time, from the moment somebody starts touching a card until it's done, lead time, measured from when the request arrived, and the cumulative flow diagram, which stacks card counts per state over time. Lower the cap, watch lead time fall, and you know the change worked.

There's a per-person version too. Agreeing that nobody opens more than two items at once turns out to be easier to honor than a column cap.

There's a place it doesn't fit. When item sizes differ wildly, a count cap loses its meaning, because a half-day card and a three-week card each count as one. In that case, splitting the items into even sizes comes before touching the cap at all.

"In progress is already at three. Don't open anything new — take a review instead."

Specifying what the behavior should be once the cap is reached.

"Let's drop the cap from four to three. Cards are sitting in one column too long."

Proposing to change the flow by adjusting the number rather than the people.

"Review keeps blocking, and it isn't the cap — it's that one person does all the reviews."

Naming the bottleneck that the cap has exposed.

At Pagedeck, Theo proposed lowering the in-progress column to three, and the first two weeks were uncomfortable. An hour or two a day appeared in which hands were free and nothing new could be opened. From the fourth week, cards finished per week went from three to seven. The freed time went into reviews and into cards waiting on acceptance, and what had been stacked up drained all at once.

Mia has recorded the in-progress card count next to the finished count every week since. In some weeks the in-progress number creeps up, and that week is when the cap started being ignored.

The most common position is that a cap reduces productivity, because it reads as a rule telling available people not to work. But what this rule reduces is the number of starts and what it increases is the number of finishes. Whether twelve or six things are open, the amount a team completes in a week depends on its people and their skill — and holding twelve at once scatters that amount across twelve cards so nothing reaches done. Cut to six and the same amount gathers onto six cards, and roughly half of them finish. Change what you measure from starts to finishes and what this rule does becomes visible immediately.

The other frequent belief is that free hands should start something new, a habit built on reading idle people as waste. But that spare time is what creates flow. In a pull system, where whoever has capacity pulls the next card, what they pull isn't new work but work already backed up ahead of them. On a team where everybody is 100 percent busy, nobody is available to unblock a stuck card, so it stands for days, and those days add straight onto the lead time. Whether to fill up people's capacity or to fill up the flow of work is the question this rule asks.