WIP Limits in Kanban: Accelerating Deliveries

Resposta Rápida (Featured Snippet):
WIP (Work In Progress) limits são tetos máximos de tarefas em cada estágio de um fluxo de trabalho (e.g., máximo 4 features em desenvolvimento). Parecem contraditórios (“menos tarefas ≠mais rápido?”), mas na verdade reduzem contexto-switching, aumentam foco, e diminuem lead time — tudo porque reduzem filas e multi-tasking.

TL;DR (5 bullets):
– Paradoxo do WIP: limitar trabalho em progresso = entregar mais rápido
– Contexto-switching: dev com 5 tarefas paralelas é 30% menos produtivo
– Fila = atraso: se Dev tem 8 tarefas e 4 slots, 4 ficam esperando (WIP limit força ação)
– Cálculo: WIP limit ≈ (tempo médio de conclusão / tempo de ciclo)
– Resultado: lead time cai 30-50%, qualidade melhora, equipe menos estressada

Full Article

The Invisible Problem: Multitasking and Context Switching

Real scenario:

Dev is working on Feature A. PM: "Can you pause? Feature B is urgent." Dev pauses A and starts B. While working on B, the architect asks for help with C. Dev leaves B and looks at C (10 min). Returns to B. But has forgotten the context and spends 5 min rereading the code.

One hour later: Dev completed 10 minutes of actual work. He spent 50 minutes context switching.

WIP limits prevent this chaos.

It says: "Dev, you can have a maximum of three tasks running in parallel. If you have three, you can't take on any more until you finish one."

Result:

• Dev focuses, finishes Feature B in 2 days (vs. 4 days with multitasking)
• Feature A begins when B ends (it waited, but was not blocked, it just waited).
• Better quality (fewer bugs due to distraction)
• Less stressed team (“wip limits saved me from going crazy”)

Theory: Why It Works

Based on queueing theory and Little's Law:

Lead Time = (WIP à— Cycle Time) / Throughput

Numerical example:

Same speed (2 tasks/day), but lead time drops 5x.

Why? Because with WIP limits, tasks don't sit in a queue waiting. They flow quickly.

Practical Calculation of WIP Limit

Approximate formula:

WIP Limit = Número de pessoas na fase à— Tempo de conclusão típico (dias)

Example: Development Phase

• Team: 5 developers
• Typical feature completion time: 1.5 days
• WIP limit = 5 à— 1.5 ≈ 7-8 features

But this is based on maximum load. A slightly lower WIP limit is recommended to create "pull" (prioritization). Example:

• Ideal: 6 features in development (instead of 8)
• If dev finishes, the next feature in the backlog automatically enters
• If it reaches 6, no new people can enter (waiting)

Real Example: Kanban Board with WIP Limits

Imagine a team of 8 people (2 designers, 3 developers, 2 QA, 1 PM):

┌────────────────────────────────────────────────────┐
│              KANBAN BOARD — PRODUTO APP             │
├────────────────────────────────────────────────────┤
│                                                     │
│  BACKLOG          DESIGN      DEV         QA    DONE│
│  (unlimited)      (2)         (6)         (3)   (   │
│                                                     │
│  ┌─────────────┐ ┌────────┐ ┌──────────┐           │
│  │ Feature 15  │ │Feature │ │Feature 8 │ ┌──────┐ │
│  └─────────────┘ │   7    │ │ (60%)    │ │Feat7 │ │
│                  └────────┘ └──────────┘ └──────┘ │
│  ┌─────────────┐ ┌────────┐ ┌──────────┐ ┌──────┐ │
│  │ Feature 16  │ │Feature │ │Feature 9 │ │Feat6 │ │
│  └─────────────┘ │   8    │ │ (30%)    │ └──────┘ │
│                  │ (new)  │ └──────────┘           │
│  ┌─────────────┐ └────────┘ ┌──────────┐ ┌──────┐ │
│  │ Feature 17  │            │Feature10 │ │Feat5 │ │
│  └─────────────┘            │ (review) │ └──────┘ │
│                             └──────────┘           │
│                             ┌──────────┐           │
│                             │Feature 11│           │
│                             │(blocked) │           │
│                             └──────────┘           │
│                                                     │
│  Status:                                            │
│  Design: 2 em progresso (no limit)                 │
│  Dev: 6 em progresso (atingiu limit!)             │
│  QA: 3 em progresso (no limit)                    │
│                                                     │
└────────────────────────────────────────────────────┘

Interpretation:

• Design has 2 in progress. Limit is 2. If 1 is finished, pull Feature 8 from the backlog.
• Dev has 6 in progress. Reached the limit. Feature 11 is waiting for someone to finish a dev feature.
• QA has 3. Limit is 3. Full.
• Result: everyone knows what to do: finish their task to clear the queue.

Implementation: From “Unlimited” to “Limited”

Week 1-2: Diagnosis

• What is the current WIP (actual, counting everything)?
• What is the current lead time (days)?
• What is the cycle time (days) per phase?

Example:

Current state:
- WIP (Dev): 12 features (way over limit)
- Lead time: 8 dias (from backlog to done)
- Cycle time: 1.5 dias (feature é feita em 1.5 dias se não tiver bloqueio)
- Throughput: 3 features/semana

Week 3: Set WIP Limits

Based on formula and diagnosis:

Dev phase: 5 people à— 1.5 days = 7.5, but set limit to 6 (create pull)
QA phase: 2 people à— 1 day = 2, set limit to 3 (buffer for testing)
Design: 1 person à— 2 days = 2, set limit to 2

Week 4: Implement & Communicate

• Update board (Kanban, Jira, AgilePlace, etc.)
• Communicate boundaries to the team
• Explicar: “Isso não é punição. à‰ para a gente trabalhar melhor.”

Week 5-8: Monitor and Adjust

• Measure new lead time
• Identify blockers (why is the feature blocked?)
• Adjust limits if necessary

Expected result (after 4 weeks):

New state:
- WIP (Dev): 6 features (limit reached but stable)
- Lead time: 3-4 dias (from backlog to done)
- Throughput: 4-5 features/semana (melhor!)
- Team satisfaction: +30% (menos stress, mais foco)

Dynamics: Exercise “Multitasking vs. WIP Limit”

(To convince the team that WIP limits work)

Part 1: Multitasking Simulation

The team performs five simple tasks (counting numbers, writing names, etc.) in parallel for three minutes. Stopwatch.

Result: "Wow, 30% incomplete, a lot of chaos."

Part 2: Same tasks, WIP Limit = 2

The team completes one task, then moves on to the next. Three minutes again.

Result: "All tasks completed, faster!"

→ Prova na prática que WIP limits funcionam.

For Technicians:

Pull algorithm in WIP limit:

def pull_next_feature(board):
    """
    Quando uma feature move para 'Done',
    pull a próxima de 'Backlog' se houver espaço.
    """
    for phase in board.phases:
        if phase.wip < phase.wip_limit and phase.next_backlog:
            next_feature = phase.backlog.pop()
            phase.add(next_feature)
            notify_team(f"New feature pulled: {next_feature}")

def block_if_at_limit(feature, phase):
    """Bloqueia nova feature se atingiu WIP limit."""
    if phase.wip_count >= phase.wip_limit:
        feature.status = "WAITING"
        log_blocker(feature, phase)
        return False
    return True

Integration with Planview AgilePlace:

AgilePlace Board
├── Column 1: Backlog
├── Column 2: Design (WIP limit: 2)
│   ├── Auto-rule: when feature finishes, pull next from Backlog
│   └── Alert: if WIP >= limit, highlight
├── Column 3: Dev (WIP limit: 6)
│   └── Color coding: green (below limit), yellow (at limit), red (over limit)
├── Column 4: QA (WIP limit: 3)
└── Column 5: Done

Metrics:
├── WIP trend: graph over time
├── Lead time: average days per feature
├── Cycle time: average days in each phase
├── Throughput: features per week
└── Blocked items: features waiting (alert if > 3 days)

Checklist: Implementing WIP Limits

• [ ] Diagnosis: measure current WIP, lead time, and cycle time
• [ ] Calculation: formula for each phase
• [ ] Definition: set WIP limit per phase (conservative to start with)
• [ ] Communication: explain to the team why and how it works
• [ ] Setup: configure board (Kanban, Jira, AgilePlace)
• [ ] Monitor: track lead time, blockers, throughput
• [ ] Adjustment: increase/decrease limits based on data (not intuition)

If You Only Do 3 Things...

1. Calcule WIP limit realista: (People à— Cycle Time). Comece conservador.

2. Configure board to enforce: Kanban board (physical or digital) visually shows when limit has been reached.

3. Measure lead time before and after: The biggest motivator is seeing lead time drop by 30-50%.

Frequently Asked Questions

Q: Don't WIP limits cause work to pile up?
A: No, quite the opposite. It piles up less because it pulls faster (without multitasking).

Q: What is the ideal WIP limit?
A: The formula is a guide. Adjust based on results (lead time, throughput, team happiness).

P: E se um dev fica ocioso (não tem feature para fazer)?
R: à“timo! Significa fluxo está ótimo. Dev pode: ajudar outro, fazer tech debt, pesquisar.

Q: Does it work for support/operational (not just development)?
A: Yes! Support can have a WIP limit of 5 tickets in parallel. The queue is visible, the priority is clear.

Reading & References

• Kanban: Successful Change Management (David J. Anderson)
• Little's Law in Queueing Theory
• Planview AgilePlace documentation

Next Steps

Is your team overwhelmed with too many tasks running in parallel? Is lead time too long? We implement WIP limits that reduce context switching and speed up delivery. Practical demo: we look at your board data and show you the potential impact. Schedule a session.

Related Reading

• Enterprise Kanban
• Planview AgilePlace
• Kanban Metrics
• Capacity Planning

Discover Planview solutions

See Full Bio