WIP Limits Kanban | Flow Optimization & Throughput

Implement WIP limits to improve flow, reduce context switching, and increase throughput. GitScrum enforces soft/hard limits with visual indicators for teams.

8 min read

Work in Progress (WIP) limits are the most powerful lever for improving flow. By limiting how much work is in progress simultaneously, you force completion over starting, reduce context switching, and often increase throughput while lowering stress.

WIP Limit Benefits

Understanding WIP Limits

The Flow Principle

WIP LIMITS AND FLOW
═══════════════════

SCENARIO A: No WIP limits
─────────────────────────────────────
Developer starts 5 things:
├── Task 1: 40% done
├── Task 2: 60% done
├── Task 3: 20% done
├── Task 4: 10% done
└── Task 5: 5% done

Status: 0 tasks complete
Context switches: Many
Cycle time: Long
Stress: High

SCENARIO B: WIP limit of 2
─────────────────────────────────────
Developer can only have 2 things:
├── Task 1: 100% done ✓
├── Task 2: 100% done ✓
├── Task 3: 80% (working on it)
├── Task 4: Not started
└── Task 5: Not started

Status: 2 tasks complete
Context switches: Minimal
Cycle time: Short
Stress: Lower

KEY INSIGHT:
Less work in progress = more work complete

Why It Works

THE MECHANICS OF WIP LIMITS
═══════════════════════════

1. CONTEXT SWITCH REDUCTION
─────────────────────────────────────
Each context switch: 20-30 min recovery time
5 tasks/day switches: 2+ hours lost
2 tasks/day switches: 30 min lost
Saved: 1.5+ hours of productive time

2. FORCED COMPLETION
─────────────────────────────────────
Can't start new → Must finish current
"But I'm blocked" → Help unblock or wait
Result: Team helps each other finish

3. BOTTLENECK VISIBILITY
─────────────────────────────────────
Without limits:
Work piles everywhere, bottleneck unclear

With limits:
Work stops entering at bottleneck
Bottleneck becomes obvious
Team addresses it

4. REDUCED CYCLE TIME
─────────────────────────────────────
Little's Law: Cycle Time = WIP / Throughput

Same throughput, less WIP = faster cycle time
Items complete faster
Faster feedback
Less inventory

Setting WIP Limits

Column Limits

COLUMN WIP LIMIT GUIDELINES
═══════════════════════════

STARTING POINTS:
─────────────────────────────────────
Team of 5 developers:

Backlog:     No limit (pool of work)
Ready:       10 (2× team size)
In Progress: 8 (1.5× team size)
Review:      4 (bottleneck-prone, keep low)
Testing:     5 (1× team size)
Done:        No limit

BOARD VISUALIZATION:
─────────────────────────────────────
┌─────────────────────────────────────────────────────────┐
│ Backlog│ Ready    │ Progress │ Review │ Test │ Done   │
│   ∞    │ max: 10  │ max: 8   │ max: 4 │max: 5│   ∞    │
├─────────────────────────────────────────────────────────┤
│ [...]  │ [T1]     │ [T5]     │ [T9]   │ [T11]│ [Done] │
│ [...]  │ [T2]     │ [T6]     │ [T10]  │ [T12]│        │
│ [...]  │ [T3]     │ [T7]     │ ⚠️ 3/4 │      │        │
│ [...]  │ [T4]     │ [T8]     │        │      │        │
│        │ 4/10     │ 4/8      │        │ 2/5  │        │
└─────────────────────────────────────────────────────────┘

ADJUSTMENT:
├── If column always at limit → Maybe too low
├── If column rarely at limit → Maybe too high
├── Watch for flow, not comfort
└── Tension is the point

Personal Limits

PERSONAL WIP LIMITS
═══════════════════

GUIDELINE: 2 items per person
─────────────────────────────────────
Developer can have:
├── 1 main task (focused work)
├── 1 backup task (if blocked)
└── Not more

WHY 2:
├── 1 item: If blocked, you're stuck
├── 2 items: If blocked, have backup
├── 3+ items: Context switching begins
└── 2 is the sweet spot

ENFORCEMENT:
─────────────────────────────────────
In standup:
"Sarah, I see you have 3 items in progress.
Which one are you focusing on?"

In planning:
"Mike already has 2 items. Let's not
assign more until he completes one."

EXCEPTIONS:
├── Small tasks (< 2 hours) maybe stack
├── Waiting tasks don't count fully
├── But: Don't game the system
└── Spirit of the limit matters

Enforcement

Respecting Limits

WIP LIMIT ENFORCEMENT
═════════════════════

WHEN LIMIT IS HIT:
─────────────────────────────────────
Developer wants to start new task.
Review column at limit (4/4).

OPTIONS:
├── 1. Help review existing PRs
│      → Reduce Review count, make room
│
├── 2. Wait
│      → Don't start something you can't finish
│
├── 3. Pair with reviewer
│      → Learn and help simultaneously
│
└── 4. Work on something else
       → Not ideal, but sometimes necessary

NOT ACCEPTABLE:
├── "I'll just start anyway"
├── "The limit doesn't apply to urgent work"
├── "I'll move it through quickly"
└── These defeat the purpose

LEADERSHIP ROLE:
├── Model respecting limits
├── Don't pressure to break limits
├── Celebrate constraint-following
└── Address systemic bottlenecks

Handling Violations

WHEN LIMITS ARE EXCEEDED
════════════════════════

TEMPORARY BREACH:
─────────────────────────────────────
Sometimes work gets stuck:
├── Blocker emerged after starting
├── Urgent item must be added
├── Handoff during transition

Response:
├── Acknowledge the breach
├── Don't add more until resolved
├── Prioritize reducing back to limit
├── Discuss in standup

CHRONIC BREACH:
─────────────────────────────────────
If column always over limit:
├── Limit may be too low (rare)
├── More likely: systemic issue

Investigate:
├── Why is work stuck?
├── What's the bottleneck?
├── Is limit being respected?
├── Are people helping each other?

Action:
├── Address root cause
├── Maybe adjust limit
├── Re-commit to discipline
├── Don't just raise limit to match reality

Tuning Limits

Finding the Right Level

WIP LIMIT TUNING PROCESS
════════════════════════

STEP 1: Start conservative
─────────────────────────────────────
├── Set limits lower than comfortable
├── Team will feel tension
├── That's intentional
└── Observe for 2-3 sprints

STEP 2: Observe behavior
─────────────────────────────────────
Too low if:
├── People idle waiting
├── Blocked with no backup
├── Frustration high
├── Helping each other constantly

Too high if:
├── Never hitting limits
├── No behavior change
├── Still context switching
├── No visibility improvement

STEP 3: Adjust incrementally
─────────────────────────────────────
├── Change by 1-2, not 50%
├── Wait 2 sprints to evaluate
├── One change at a time
└── Based on data, not complaints

STEP 4: Stabilize
─────────────────────────────────────
├── When flow feels right
├── Slight tension but not frustrating
├── Bottlenecks visible
├── Cycle time improving
└── Keep these limits

Metrics to Watch

WIP LIMIT EFFECTIVENESS METRICS
═══════════════════════════════

CYCLE TIME:
─────────────────────────────────────
Before WIP limits: 7 days average
After WIP limits: 4 days average
Improvement: 43%

THROUGHPUT:
─────────────────────────────────────
Before: 12 items/sprint
After: 14 items/sprint
(Less WIP, same or more throughput)

QUALITY:
─────────────────────────────────────
Before: 5 bugs/sprint
After: 3 bugs/sprint
(More focus = fewer mistakes)

BLOCKED TIME:
─────────────────────────────────────
Before: Blockers hidden for days
After: Blockers visible immediately
Faster resolution

TEAM HEALTH:
─────────────────────────────────────
Before: Stressed, always juggling
After: Focused, completing work
Better morale

GitScrum Configuration

WIP Limit Setup

GITSCRUM WIP LIMITS
═══════════════════

BOARD CONFIGURATION:
─────────────────────────────────────
Settings → Board → Columns

For each column:
├── Enable WIP limit
├── Set limit number
├── Choose warning threshold
└── Set blocking behavior

OPTIONS:
├── Soft limit: Warning only
│   Shows: ⚠️ 5/4 (over limit)
│   Allows adding
│
├── Hard limit: Blocks adding
│   Shows: 🚫 4/4 (at limit)
│   Cannot add more
│
└── Choose based on team discipline

VISUALIZATION:
─────────────────────────────────────
Column header shows: count/limit
├── Green: Under limit
├── Yellow: At limit
├── Red: Over limit
└── Visual cue for team

PERSONAL LIMITS:
─────────────────────────────────────
View → Filter by assignee
See each person's WIP
Alert if individual > 2 items in progress

Best Practices

For WIP Limits

Anti-Patterns

WIP LIMIT MISTAKES:
✗ Limits too high (no effect)
✗ Limits ignored when inconvenient
✗ Raised limits to avoid tension
✗ No enforcement mechanism
✗ Not helping each other finish
✗ Gaming (artificial task splits)
✗ Blocking columns with no action
✗ Never adjusting after initial set

Related Solutions

• Identifying bottlenecks in development workflow
• Improving team productivity
• Kanban vs Scrum: Choosing the right methodology