WIP Limits

What it is

Work In Progress (WIP) limits are a foundational Kanban practice that cap the number of work items allowed in each stage of a workflow. When a column reaches its limit, no new items can enter until something moves forward.

This creates a pull system: work is pulled into the next stage only when there is capacity, rather than pushed forward regardless of downstream ability to handle it.

• Each column has a max. The limit is displayed on the Kanban board, usually in the column header.
• When full, no new items enter. Team members must help clear work from the bottleneck column before starting something new.
• Forces teams to address blockages. Instead of starting fresh work, the team swarms to resolve stuck items.
• Reduces context switching. Fewer concurrent tasks means deeper focus and higher quality.

When to use it

Implement WIP limits as soon as you begin using a Kanban board. They are not an advanced technique—they are the mechanism that makes Kanban work.

Start with a limit that feels slightly uncomfortable. If it never feels tight, it is probably too high.

Key concepts

The Pull System

Work moves right when the next stage has capacity to pull it. This prevents overloading downstream stages and keeps flow smooth.

Setting Limits

A common starting point is the number of team members plus one. For a team of 6, try a limit of 7 in "In Progress" and 3 in "Code Review." Adjust based on observed behaviour.

WIP Limit Breaches

A breach occurs when work enters a column that is already at its limit. Breaches are signals, not failures. They indicate a policy decision, a blocked item, or a limit that needs adjustment.

Team vs Individual WIP

Limit work at the team level. Individual WIP limits create silos and discourage collaboration. The goal is to finish work, not to optimise individual utilisation.

WIP Limit Calculation Methodology

Formula: WIP Limit = (Team Size × Average Items per Person) + Buffer

Explanation:

• Team Size: 6 developers = 6
• Average Items per Person: On average, how many work items does one person work on before finishing? Usually 1 (one task at a time is ideal, but some people multitask or have waiting time). Use 1 if possible.
• Buffer: Add 1-2 to allow for slight overflow when someone needs to unblock a peer.

Examples:

• Team of 6, ideal state (1 item per person): 6 × 1 + 1 = 7 WIP limit
• Team of 10, realistic (some waiting, some multitasking): 10 × 1.2 + 2 = 14 WIP limit
• Team of 4 with high context switching: 4 × 1.5 + 1 = 7 WIP limit (same as team of 6, because of inefficiency)

Worked Example: Calculating Optimal WIP for a 6-Person Team

Team composition: 4 backend developers, 1 frontend developer, 1 QA engineer

Workflow stages: "To Do" → "In Progress" → "Code Review" → "In Test" → "Done"

Baseline observation (no limits):

• "In Progress" average: 12 items (people start too much)
• "Code Review" average: 8 items (review is slow, items pile up)
• "In Test" average: 5 items (QA is one person, can't keep up)
• Lead time: 20 days (too long)

Proposed limits (conservative to start):

• "In Progress": 6 (one per person, forces finishing before starting new)
• "Code Review": 4 (slow it down, catch quality earlier)
• "In Test": 3 (protect the QA, don't dump untestable work)

Result after 2 sprints:

• Items complete faster (cycle time drops from 8 days to 4 days)
• Focus improves (less context switching)
• Lead time drops to 12 days
• Quality goes up (code is more thoroughly reviewed because bottleneck is visible)
• But: "In Progress" limit is breached twice (urgent bugs pushed in, agreed on policy exception)

Refinement: After 2 months, team decides WIP limits are working. They lower "Code Review" to 3 (easier to review now, less backlog), keep "In Test" at 3 (QA still the constraint).

Experiment Framework: Try WIP Limit, Measure Impact

1. Baseline (Week 1-2): Measure current state. Record: cycle time, lead time, blocker frequency, team morale.
2. Set limits (Week 3): Propose WIP limits based on team size. "To Do" doesn't have a limit. "In Progress" = 1 per person. "Code Review" = 50% of In Progress. "In Test" = 2-3 (depends on team).
3. Run experiment (Week 3-6, one sprint): Use the limits strictly. Treat breaches as learning, not failure.
4. Measure (Week 7): Compare to baseline. Did cycle time improve? Did lead time improve? Did team morale change? Did blocker rate change?
5. Adjust (Week 8): Based on data, tweak limits. If "Code Review" is always full but "In Test" is empty, lower code review limit and raise test limit.
6. Iterate: Run another cycle. Measure again in 4 weeks.

What Happens When WIP is Too High

• Context switching: A developer with 4 items in progress switches between them constantly. Each switch has a 10-minute ramp-up cost. Productivity drops 40%.
• Slow delivery: With 20 items in "In Progress," nothing finishes. Lead time balloons to 30+ days.
• Quality issues: Rushed code, incomplete tests, sloppy review. Bugs hidden until late stages, expensive to fix.
• Blocker visibility: With high WIP, blockers hide. A team member can look busy (many items started) while actually stuck (all items blocked).
• Team burnout: Switching constantly feels chaotic. Team feels busy but unproductive. Morale drops.

Tools for Enforcing WIP Limits

• Physical Kanban board: Index cards in columns. Limits are visible as physical space. When a column is full, you stop filling it.
• Jira: Set "Issue Limit" on each board column. Jira flags when limit is exceeded.
• GitHub Projects: Columns support limits (beta feature in some versions). Use a rule to warn when limit is approached.
• Azure DevOps: Built-in WIP limits on board columns. Easy to set and enforce.
• Trello Power-Ups: Third-party integrations that show WIP limit badges on columns.

Common pitfalls

Pitfall	Why it hurts	What to do instead
Limits too high	No tension in the system; work piles up silently.	Lower until the limit is occasionally uncomfortable.
Ignoring limits for "urgent" work	Every item becomes urgent; limits become meaningless.	Escalate the limit temporarily and record the reason.
Same limit for every column	Stages have different capacities and purposes.	Tailor limits to each stage based on flow data.
Treating breaches as failure	Team hides breaches rather than learning from them.	Treat breaches as data. Discuss in standups.
Not adjusting limits	Team composition and work types change over time.	Review limits in retrospectives at least monthly.

NZ context

New Zealand software teams are often small—5 to 7 people. At this scale, modest WIP limits have dramatic effects. A limit of 5 in "In Progress" for a 6-person team forces collaboration and exposes blockages within days rather than weeks.

Many NZ teams operate in mixed waterfall-agile environments where upstream business analysts or product owners push work regardless of capacity. WIP limits give the delivery team a concrete policy to push back: "The board is full. We can pull this when something moves."

Career level guidance

Junior: Respect the WIP limit. When your column is full, ask how you can help move existing work forward rather than starting something new. Learn to see the limit as a team tool, not a personal restriction.

Senior: Help set initial limits and coach others through breaches. Watch for patterns—if one column is always full, that is where your process improvement effort belongs.

Test Lead: Use WIP limits to protect test capacity. A dedicated "In Test" column with a strict limit prevents the team from dumping untestable work and walking away. Review limit data in retrospectives and adjust based on release cadence.