A delivery board with every column full is not evidence of productivity. It is usually evidence that work has been started faster than it can be completed. Knowing when to apply WIP limits gives teams a practical way to stop that pattern, expose the constraint, and restore control over flow.
For software and IT teams, work in progress limits are not a Kanban ritual to copy from a textbook. They are an operational control. Applied at the right point, they reduce context switching, protect quality, shorten lead time and force meaningful conversations about capacity. Applied badly, they can become arbitrary targets that block useful work and frustrate experienced engineers.
What a WIP limit is designed to control
A WIP limit sets the maximum number of work items allowed in a workflow stage or across a system at one time. If the testing column has a limit of four, the team cannot pull a fifth item into testing until one of the existing items has moved on.
The purpose is not to keep people idle. The purpose is to prevent the system from hiding queues behind apparent busyness. When a stage reaches its limit, the team should swarm on the work already there, remove a dependency, fix a defect, clarify an acceptance criterion or help the constrained specialist finish the item.
This changes the operating question from, "What can I start next?" to, "What must we finish before taking on more?" That shift is where flow improves.
When to apply WIP limits: the clear signals
Apply WIP limits when the team has a repeatable workflow and can see work moving through identifiable stages. You do not need a perfect Kanban implementation or a mature flow metrics programme. You do need enough visibility to recognise where work waits, returns or accumulates.
The strongest signal is a persistent queue. If tickets repeatedly build up in code review, test, security assurance, product validation or deployment, a WIP limit makes that queue impossible to ignore. It will not remove the underlying constraint by itself, but it stops upstream work from making the constraint worse.
Apply limits when cycle times are unpredictable. A team may complete roughly the same number of items each month while individual items take wildly different amounts of time. This is often caused by too much parallel work, late discovery of blockers and work ageing quietly in the system. Limiting active items makes delays visible earlier and encourages smaller, finishable slices.
Use WIP limits when quality degrades under delivery pressure. A growing defect backlog, rushed test coverage and recurring rework are common signs that teams are feeding more work into development than their quality practices can support. A limit on development, review or testing can protect the time needed to complete work to the agreed standard.
They are also valuable when specialists become bottlenecks. One platform engineer, security reviewer, UX designer or database specialist can be asked to support several streams at once. Without a limit, every requester sees their work as urgent and the specialist pays for that urgency through constant switching. A WIP limit creates a disciplined queue and gives leaders data for a capacity decision.
Finally, apply limits when the team is changing its ways of working. During a migration to a new architecture, a major release programme or a shift towards continuous delivery, more parallel activity can feel safer. In practice, unmanaged parallelism often creates coordination debt. A temporary, tighter limit gives the team a stable baseline while it learns where the new process is fragile.
Start where the flow is breaking
Do not place limits on every column simply because the board supports it. Start with the point where the system is visibly struggling. For many teams, that is work in development. For others, it is code review or testing, where items wait for scarce expertise or environments.
A useful first move is to set a limit on the column immediately before the bottleneck. If testing is overloaded, limit the number of items that can be ready for test or actively in development. This reduces the rate at which new work arrives at the constrained stage. The team then has room to clear the queue rather than continuously adding to it.
Set the initial number using real capacity, not optimism. If two testers can usually work effectively on three items at once because one item often needs environment support, a test WIP limit of three is more credible than a limit of eight. The limit should create a small amount of productive tension. If it is never reached, it is probably too high. If it is constantly blocking work for reasons outside the team’s control, inspect the policy and the dependency rather than treating the limit as sacred.
For a cross-functional product team, a team-level WIP limit can be more useful than separate limits for every individual. It discourages the false efficiency of giving each person their own ticket and makes collaboration the default. For a service team handling urgent incidents alongside planned delivery, separate classes of service may be necessary. A critical production incident should not be trapped behind a standard feature limit, but it must still be visible and governed.
Set explicit rules before enforcing the limit
A WIP limit works only when people understand what counts as work in progress and what happens when the limit is reached. Ambiguity creates workarounds: tickets moved to a vague holding column, subtasks created to bypass the policy, or items marked done before they are genuinely usable.
Define entry and exit criteria for the limited stage. For example, an item may enter development only when acceptance criteria, designs and dependencies are sufficiently understood. It leaves development only when code is integrated, peer-reviewed and ready for the next agreed activity. Your exact definition depends on the team’s delivery model, but the policy must be observable.
Agree the response when a column is full. In most cases, the response should be to help move existing work: pair on a story, review code, clarify requirements, reproduce a defect or remove an external blocker. It should not be to start a different item because that feels more convenient.
Make exceptions explicit. Expedite work, regulatory fixes and genuine incidents may justify an override. Record the reason and review the frequency. Exceptions that occur every week are not exceptions. They are evidence that intake, prioritisation or capacity planning needs attention.
Avoid the common implementation mistakes
The first mistake is treating WIP limits as a utilisation tool. A limit is not there to prove that every individual is busy. In fact, a healthy limit may reveal short periods where someone is available to help elsewhere, improve automation, reduce technical debt or strengthen the workflow. That is capacity being used intelligently, not wasted.
The second is setting limits from a spreadsheet without observing the work. Historical throughput can inform a starting point, but workflow design requires direct inspection. Watch stand-ups, replenishment discussions, review queues and hand-offs. Speak to the people doing the work. The constraint may be unclear requirements, unstable environments or delayed decisions rather than a shortage of engineers.
The third is applying limits to work that has not been sliced properly. A feature that takes six weeks and involves multiple teams will consume a WIP slot for too long to offer useful control. Break it into thin, valuable increments where possible. WIP limits and sensible work item sizing reinforce each other.
The fourth is using limits without measuring the result. Track work item age, cycle time, throughput, blocked time and defect escape rate. You are looking for a more stable flow, not simply fewer items on the board. If cycle time falls but escaped defects rise, the team may be pushing work through too quickly. If throughput dips briefly while ageing work is cleared, that may be a necessary correction rather than failure.
Review limits as the system changes
WIP limits are operating hypotheses, not permanent rules. Review them after a meaningful period of use, usually long enough to see several delivery cycles. Look at whether the limit exposed useful problems and whether the team changed its behaviour when the limit was reached.
Increase a limit only when the relevant stage has demonstrably gained capacity or reduced variability. New test automation, a simplified approval process or an additional skilled team member may justify a change. Do not increase it merely because the team dislikes seeing a full column. A full column is often the signal that leadership needs.
Decrease a limit when work continues to age, quality suffers or coordination overhead rises. Tighter limits can feel uncomfortable at first because they prevent the reassuring act of starting more. Yet they often create the conditions for faster completion and more reliable forecasting.
The practical test is simple: when a limit is reached, does the team collaborate to finish work, or does it find a way around the board? If the answer is the latter, the issue is not just the number. It is the working agreement, the incentives or the leadership behaviour surrounding flow.
A well-applied WIP limit gives a delivery team permission to finish properly. Use that permission to make bottlenecks visible, improve the system around the work and build predictability one completed item at a time.