Wip limit

A WIP (Work in Progress) Limit is an explicit constraint on how many work items can be in a particular state at any given time. When a stage reaches its WIP limit, no new work can enter until existing work moves out. This simple mechanism - a number written on a Kanban board column - fundamentally changes how teams work by forcing focus, exposing problems, and improving flow.

Why it matters

WIP limits matter because they convert good intentions into enforced behavior. Most teams know they should focus and avoid overloading. But without explicit limits, the pressure to start new work always wins. There's always a stakeholder asking for something, always a shiny new feature, always a reason to begin another task.

WIP limits remove the decision from the moment. The rule is clear: if the limit says 3, you can't start a 4th item until something moves out. This shifts conversations from "should we start this?" to "how do we finish something to make room?"

How wip limits work

The mechanics are straightforward:

Set limits per column. Each stage of your workflow - To Do, Development, Review, Testing - gets a maximum number of items it can contain.

Enforce the limits. When a column reaches its limit, work stops entering. Team members must help clear the bottleneck rather than starting new tasks.

Make limits visible. Write the limit number on the column header. "Development (3)" means no more than 3 items can be in development.

Respect the constraint. The limit only works if teams treat it as inviolable. "Just this once" exceptions undermine the entire system.

Benefits of wip limits

Faster flow. Counterintuitively, limiting how much you start accelerates how much you finish. Items move through the system faster when they're not competing for attention.

Exposed bottlenecks. When limits block progress, they reveal where the real constraints are. A development limit reached while testing sits empty shows development is the bottleneck.

Forced collaboration. When someone can't start new work, they're motivated to help colleagues finish. This creates natural swarming on stuck items.

Reduced context switching. With fewer items in flight, people focus more deeply on fewer things, reducing the cognitive overhead of switching.

Better predictability. Lower, more consistent WIP produces more consistent lead times. Teams can forecast more reliably.

Visible problems. Work stuck at a limit becomes immediately visible. Problems can't hide in a sea of partially-done items.

Setting wip limits

Determining the right WIP limit requires experimentation:

Start with team size. A common starting point is limiting WIP to one item per person, or slightly more to allow for blocked items and collaboration.

Observe and adjust. Begin with a limit that feels slightly constraining. If work flows smoothly, lower it. If the team constantly blocks, raise it slightly.

Different limits per stage. Stages with different capacity need different limits. Testing might have a limit of 2 while development has a limit of 4.

Total system limits. Some teams limit total WIP across all stages rather than per-stage limits. This is simpler but provides less visibility into bottlenecks.

Account for variability. Work items vary in size. Limits based on item count work better when items are relatively similar in scope.

Common wip limit patterns

Individual limits. Some teams set personal WIP limits - "No one works on more than 2 items simultaneously." This addresses individual overload.

Column limits. The classic Kanban approach. Each workflow stage has its own limit.

Swimlane limits. When boards have horizontal swimlanes (by priority, team, or type), each swimlane can have its own limits.

Cumulative limits. Instead of per-column limits, set a limit that's cumulative across multiple columns. "No more than 8 items across Development + Review."

Making wip limits work

WIP limits require discipline to be effective:

Leadership support. If leaders pressure teams to bypass limits "just this once," the system collapses. Leaders must visibly support the constraints.

Team buy-in. Limits imposed without understanding breed resentment. Teams that understand why limits help embrace them.

Consistent enforcement. Every exception teaches the team that limits are negotiable. Treat limits as firm constraints, not guidelines.

Bottleneck response. When limits block progress, the response must be to address the bottleneck - not to raise the limit. Help test if testing is backed up. Help review if review is the constraint.

Regular review. As teams improve and circumstances change, limits should be revisited. But change deliberately, not reactively.

Challenges and solutions

"But I'm blocked and can't help." Sometimes work is blocked on external dependencies and the team member genuinely can't help elsewhere. Some teams allow one "blocked" lane that doesn't count against limits, but this can be abused.

"Work items are too different in size." If one item is a small bug fix and another is a major feature, counting them equally creates problems. Consider using points instead of counts, or break large items into smaller pieces.

"Stakeholders demand faster starts." WIP limits may mean stakeholders wait longer to see work begin. Help them understand that faster starts mean slower finishes, and that flow optimization serves everyone.

"We just need to increase capacity." Adding capacity rarely helps as much as improving flow. High WIP indicates flow problems that more people won't solve - they'll likely make it worse through coordination overhead.

Wip limits beyond development

The concept extends beyond engineering:

Product management. Limit how many features or initiatives are "in discovery" or "in roadmap planning" simultaneously.

Organization level. Limit how many major programs the company pursues at once.

Personal productivity. Limit how many projects or goals you're actively working on.

The principle remains constant: limiting work in progress improves flow and forces focus.

Starting point recommendations

For teams new to WIP limits:

These are starting points, not formulas. Observe how work flows and adjust based on evidence.

The deeper lesson

WIP limits embody a fundamental truth: we accomplish more by attempting less. In a world that celebrates busyness and multitasking, limits feel counterintuitive. But teams that embrace constraints consistently outperform teams that don't. The limit isn't a constraint on productivity - it's an enabler of it.

Tools like Klero complement WIP-limited workflows by helping teams understand which customer needs matter most, enabling better decisions about what limited WIP slots should contain to maximize customer value delivered.