A work-in-progress limit is an explicit cap on how many items may be active in a stage of work at one time, applied so that started work finishes before new work begins. This entry covers what a limit that is holding looks like, why limits erode, and the mistakes that turn them into decoration. It applies at team level and, with larger numbers, at the portfolio level described in portfolio kanban.
Why do WIP limits matter?
Every item that is started but not finished holds capacity without returning anything. Past a certain point, adding work does not add output. It spreads the same people across more items, each item waits longer between touches, and everything arrives late together. A limit is the simplest way to make that trade-off visible: when the column is full, the next item waits, and the wait is where the conversation about priorities actually happens.
What does a WIP limit that is holding look like?
The board is honest first. Every active item is on it, including the favors, side projects, and work sponsored outside the plan. A limit applied to the visible half of the work is a limit on reporting, not on work.
A full column means a real wait. When the column is at its limit and someone asks for something new, the answer is "not yet", and the request shows up in the intake queue rather than disappearing. Leadership has agreed to that in advance, so the wait is not treated as an exception to be negotiated.
When a team is blocked and the column is full, people help finish what is already started or clear the blocker instead of picking up something new.
The numbers move in the right direction. Lead time trends down and throughput holds or rises. Items do not sit aging with nobody working on them. When the limit changes, somebody can say why, and the reason is written down.
The limit is breached rarely. If a column is over its limit more than a few days a month, either the limit is wrong or the policy is not being enforced. One of the two needs fixing; leaving it as it is teaches everyone that the number is decoration.
Why do WIP limits erode?
Limits that erode tend to do so for the same few reasons.
- Work arrives through side doors. Requests that bypass intake land on individuals rather than the board, so the column looks within its limit while people are carrying twice as much.
- The limit was set at an ideal number. A limit far below what the team is carrying today gets breached on day one and is never taken seriously afterward.
- Nobody owns the exceptions. If anyone can raise the limit for a good cause, every cause becomes good enough.
- There is no portfolio limit above it. A team can hold a limit only if the portfolio stops approving more work than the teams can take. When portfolio intake is unlimited, team limits absorb the pressure until they break.
- Blockers sit. Items stuck on another team fill the column and nobody escalates them, so the limit starts to feel like the cause of the delay rather than the thing exposing it.
What mistakes do teams make with WIP limits?
- Treating the limit as a target. A column that is always exactly full has no slack to absorb a blocker or an urgent item.
- Limiting only the build column. Work piles up in review, testing, or waiting for deployment instead, and lead time does not improve.
- Saying no invisibly. A deferred request that vanishes comes back as an escalation. A deferred request that is visible in the queue can be ranked.
- Changing the limit without evidence. Raising it because the team feels busy, or lowering it because it sounds disciplined, without comparing lead time and throughput before and after.
- Leaving escalation undefined. Blockers that keep items stuck need a known path, which the Deliver practice sets out.
Where to get help
Team limits set without portfolio support tend to erode. Portfolio-level limits are set in the Align practice, and a PPM4Agile implementation puts them in place so team limits have something to lean on.
If the problem sits at team level instead, how the team is put together, how it runs its ceremonies, or how it tracks and reports work, team coaching is part of the consulting too. See the two levels of consulting.