WIP Limits & Buffers

---

The Underlying Math

Little's Law connects three variables in any queueing system: average cycle time = work in progress / throughput.¹ The mathematical conclusion is immediate: if you want cycle time to drop and throughput is roughly stable, the only lever is reducing WIP.

This is not a rule of thumb. It's a mathematical identity that holds for any stable queueing system. Teams that ignore it spend years trying to "go faster" without addressing the only mechanism that actually accomplishes it.

What a WIP Limit Is

A WIP limit is a cap on the number of items that can be in a given state at once. On a kanban board, each column (or sub-column, or swimlane) has a WIP limit visible at the top. When the limit is reached, no new item can enter that column until an existing one moves out.

The constraint is not a recommendation. It's a rule that the team enforces, and the discipline of enforcement is what makes the limit work.

Why WIP Limits Are Hard

The math is clear; the practice is hard. WIP limits feel restrictive. When the limit is reached and the team can't start a new item, the natural reaction is to break the limit "just this once." Three forces pull against the discipline:

• Idle people feel like waste. If an engineer can't pull new work because the limit is hit, the engineer feels unproductive. Leadership feels capacity is being wasted.
• Starting feels like progress. Starting new work produces a visible move on the board, which feels better than waiting.
• Stakeholders want things started. A request acknowledged ("we've started it") feels better to stakeholders than a request queued ("we'll start it when we finish current work").

None of these are right. Reinertsen's Principles of Product Development Flow demonstrates conclusively that high utilization and unbounded WIP produce dramatically worse outcomes than bounded systems.²

Setting Limits

The right WIP limit depends on the team and the column. Useful starting points:

• Per developer: 1.5 items in progress on average. Some teams pair, some work solo; the multiplier accounts for both.
• Per column: usually 2–4 for in-progress columns; can be smaller for review or test columns where the work is shared.
• Total board WIP: the sum across columns shouldn't exceed roughly 2× team size.

The right number is found empirically. Start strict; relax if the team stalls; tighten if cycle time stays poor.

What Happens When the Limit Is Hit

The discipline of the limit: when reached, the team cannot start new work. Three legitimate responses:

• Swarm. Pull people onto stuck items to finish them and free the limit.
• Investigate the block. Why is work stuck? Address the cause.
• Wait. Sometimes the right move is to do nothing for a brief period. Idle time is not waste if the alternative is starting work that compounds the queue.

The wrong response: increase the limit. Once a limit is broken regularly, it isn't a limit anymore.

Buffers

A buffer is a deliberately-sized waiting area between two workflow stages. Buffers exist because:

• Different stages have different speeds; a buffer absorbs the mismatch.
• Some stages benefit from having a queue of refined work ready to pull.
• Variable arrival rates need somewhere to land without disrupting downstream work.

Buffers have their own WIP limits — they're meant to be small. An unlimited buffer is the inventory pile-up the lean tradition exists to prevent. A bounded buffer is a useful absorber.

What Changes When Teams Adopt WIP Limits

• Cycle time drops, often dramatically. Items finish faster because they aren't competing with as many other items.
• Bottlenecks become visible. The column where WIP limits are constantly hit is the bottleneck.
• Swarming becomes routine. When you can't start new work, helping finish existing work is the obvious move.
• Quality improves. Less context-switching, more focus per item.
• Stakeholders adapt. The conversation shifts from "when will you start this?" to "what's the queue position?"

Coaching Tips

Start strict.

Set limits below where the team currently is. Tightness is the forcing function; you can always relax later.

Make the limit visible.

Big numbers at the top of each column. If the limit is in a wiki, it doesn't exist.

Don't raise it under pressure.

The first time a limit feels restrictive, the team will want to raise it. That's exactly when not to.

Teach swarming explicitly.

When the limit is hit, swarming the stuck item is the move. The team needs to know this is the answer.

Reframe idle time for leadership.

"My people are idle" is the wrong concern. "Work is stalled" is the right one. Educate leadership on the difference.

Measure before and after.

Cycle time data from before WIP limits and after is the strongest argument for keeping them. Track it.

Summary

WIP limits are the single most leveraged practice in modern flow-based agile. The math is unambiguous; the practice is uncomfortable. Teams that maintain the discipline see cycle time drop, bottlenecks become visible, and quality improve. Teams that don't end up with chronic high WIP, ballooning cycle times, and the constant low-grade dysfunction of having too much in progress at once. The discipline costs almost nothing to attempt and pays back disproportionately.

Back to Flow & Forecasting