WIP Limits: How to Set Them Without Turning Into a Process Team

Introduction

Search for WIP limits and you will find advice about per-column policies, aggregate limits across swimlanes, buffer columns with their own limits, and a formula involving team size, specialisation and class of service. All of it is sound. Almost none of it is written for a team of five.

At small scale the elaborate version has a specific failure mode: the limits become a process artefact that someone has to maintain, everyone quietly routes around, and eventually a retro agrees to remove. You end up worse off than before, because now the team has evidence that "process stuff" does not work.

The small-team version is one number.

What Is a WIP Limit and How Do You Set One?

A WIP limit is a cap on how many items may be in progress at once. When the cap is reached, nobody starts anything new until something finishes. The standard starting point for a small team is two items per person, so a team of five caps at ten, and the honest answer is that the exact number matters far less than having one at all.

That is the whole mechanism. Everything else written about WIP limits is refinement of where to apply the cap, and for a team under fifteen the answer to that is "the whole board".

Why It Works

Two reasons, one arithmetic and one human.

The arithmetic is Little's Law: average cycle time equals average WIP divided by average throughput. Throughput is hard to change quickly and WIP is trivial to change, so halving WIP roughly halves cycle time with no other intervention. This is not a productivity technique, it is a property of queues, and it holds whether or not anyone believes in it. See Little's Law for software teams.

The human reason is that partially finished work has a carrying cost nobody accounts for. Every open item is context somebody is holding, a branch drifting from main, a stakeholder who thinks the thing is nearly ready. Five items at ninety percent deliver exactly nothing. See context switching.

The One-Number Rule

Set a single limit for the whole board at two items per person. Count anything a person has actively started, including the thing they are "just finishing up". Do not exempt bugs, do not exempt small things, do not create a separate lane for urgent work with its own allowance. Every exemption is where this dies.

Two per person, not one, for a reason: a single item per person makes every blocker a full stop and the team will break the rule within a week, which teaches them the rules are breakable. Two gives one thing to switch to when the first is genuinely blocked and no more.

If two per person feels obviously too tight, it is not. Count what is actually open right now before deciding. Most small teams discover they are carrying three or four per person and have been describing it as being busy.

What to Do When You Hit the Limit

This is the part that determines whether WIP limits do anything. Hitting the limit is not a failure state. It is the mechanism working, and it is asking you a question.

There are exactly two legitimate responses:

• Swarm. Help finish something that is already in progress. Review the open pull request, pair on the stuck item, take the QA pass nobody has picked up.
• Stop. Do something that is not delivery work. Documentation, that refactor, an hour on the thing you have been avoiding. Idle capacity is uncomfortable and it is cheaper than a queue.

There is one illegitimate response, and it is the one everybody reaches for: raise the limit. If the limit moves every time it binds, it is not a limit, it is a display of the current WIP. Raise it deliberately, once, after a month of data, or not at all.

There is also a third thing that happens in practice and is worth naming: the limit is hit, and the real answer is that an item has been open for eleven days and everybody has stopped looking at it. That is the signal to go and check work item age. See aging work in progress.

WIP Limits Without Columns

Most WIP limit advice assumes a board with columns, because the limit is conventionally enforced per column: three in development, two in review. If you run continuous flow with a single prioritised list rather than columns, none of that applies and the advice appears not to translate.

It translates fine. The limit is on items with an in-progress status, wherever they sit in the list. A count is a count; the column was only ever a place to display it. In practice the column-free version is easier to hold to, because there is no arguing about whether something in review counts against the development limit.

The one thing you lose is the ability to see which stage is the bottleneck from the limit alone. For that, look at the gap between cycle time and lead time, or at flow efficiency.

What Usually Goes Wrong

The limit is set from current WIP. Someone counts fourteen open items across five people and sets the limit at fourteen. Nothing changes, because the limit never binds. Set it below where you are now or do not bother.

Urgent work is exempted. Within a month, the definition of urgent has expanded to cover most things. If genuinely urgent work is frequent enough to need an exemption, it is not urgent work, it is your actual workload, and the limit should account for it. See handling urgent requests.

Nobody counts blocked items. An item waiting on a client for nine days is occupying a slot and the cost of it is exactly why you want it visible. Excluding blocked items removes the pressure to go unblock them.

What to Do This Week

Count the items currently in progress across the team and divide by headcount. If the answer is above two, you have found something more actionable than any chart on the flow metrics guide. Set the cap at two per person on Monday and keep it for four weeks without adjusting it, then look at cycle time.

Next: throughput, to see the effect, and Little's Law, for why the effect is not a coincidence.