Setting WIP Limits

A common question: "What should our WIP limit be?"

The honest answer: We don't know. Start somewhere and adjust.

WIP limits are experiments, not calculations. Different contexts need different limits, and the right limit today might be wrong next month.

That said, there are reasonable starting points and principles to guide you.

You can set WIP limits at different levels:

Per-column limits: Each stage has its own limit.

• "Dev: 3" / "Review: 2" / "QA: 2"
• Creates balance across stages
• Prevents any one stage from becoming a bottleneck

System-wide limit: Total items in the system.

• "Maximum 15 items from Ready to Done"
• Simpler to manage
• Doesn't prevent internal bottlenecks

Per-person limits: Each person's WIP is limited.

• "Maximum 2 items per person"
• Good for knowledge work where context switching is costly
• Can be combined with column limits

Most teams use a combination: Per-column limits for the workflow, sometimes with per-person limits overlaid.

The "n or n-1" rule: Start with a limit equal to or one less than the number of people working in that stage.

If 3 developers work in the Dev column, try WIP limit of 3 or 2.

Why this works:

• Ensures people aren't idle (each can have one item)
• Creates slight pressure to collaborate (limit of n-1)
• Provides a reasonable starting point

The "2x throughput" rule: Set system WIP to roughly 2x your weekly throughput.

If you complete 8 items per week, aim for ~16 items in the system total.

Why this works:

• Implies roughly 2-week lead time
• Provides enough buffer for variation
• Prevents extreme overload

Limit is too high:

• Never hit the limit
• Items age in the column
• Context switching is constant
• Lead times are long

Limit is too low:

• Constantly hitting the limit
• People are frequently blocked/idle
• Work starves downstream stages
• Team frustration is high

Just right (for now):

• Occasional limit hits that prompt collaboration
• Work flows steadily through stages
• Lead times are reasonable
• Team feels challenged but not overwhelmed

Remember: "Just right" is dynamic. As the team improves, tighten the limits. As team composition changes, readjust.

WIP limits should evolve. Here's a healthy process:

Initial setup: Pick reasonable starting limits using the heuristics above.

Weekly observation: Are limits being hit? Too often? Never? What happens when they are?

Retro discussion: Review flow. Are limits helping? What should change?

Gradual tightening: As the team improves flow, try lowering limits. Lower limits reveal problems earlier and create more pressure for efficiency.

Loosening when needed: Changing circumstances (new team members, new work types) may require relaxing limits temporarily.

The maturity signal: Mature Kanban teams often have surprisingly low limits. They've eliminated waste and can work effectively with tight constraints.