### [WIP Limits no Kanban: Acelerando Entregas](https://twrt.com.br/wip-limits-kanban-acelera-entregas/) **Published:** janeiro 13, 2026 **Author:** Thomas Weinstein **Excerpt:** 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... **Content:** **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:** segundo Weinberg (1991), alternar entre só 2 tarefas paralelas já reduz a produtividade de cada uma em até 20% – **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, qualidade melhora, equipe menos estressada --- ### Artigo Completo **O Problema Invisível: Multitarefa e Contexto-Switching** Cenário real: Dev tá fazendo Feature A. PM: “Pode pausar? Feature B é urgente.” Dev pausa A, começa B. Enquanto tá em B, arquiteto pede ajuda com C. Dev deixa B, olha C (10 min). Volta para B. Mas esqueceu contexto, lê 5 min de código de novo. Uma hora depois: Dev completou 10 minutos de trabalho real. Passou 50 minutos em contexto-switching. **WIP limits proíbem esse caos.** Diz: “Dev, você pode ter máximo 3 tarefas em paralelo. Se tem 3, não pega mais até terminar uma.” Resultado: - Dev foca, termina Feature B em 2 dias (vs. 4 dias com multitarefa) - Feature A começa quando B termina (esperou, mas não foram “blocked”, só esperou) - Qualidade melhor (menos bugs por distração) - Equipe menos estressada (“wip limits me salvaram da loucura”) --- **Teoria: Por Que Funciona** Baseado em **queueing theory** e **Little’s Law**: ``` Lead Time = (WIP × Cycle Time) / Throughput ``` Exemplo numérico: MétricaSem WIP LimitCom WIP LimitWIP20 tarefas4 tarefasCycle time0.5 dias (geral)0.5 dias (geral)Throughput2 tarefas/dia2 tarefas/dia**Lead time**(20 × 0.5) / 2 = **5 dias**(4 × 0.5) / 2 = **1 dia****Mesma velocidade (2 tarefas/dia), mas lead time cai 5x.** Por quê? Porque com WIP limite, tarefas não ficam em fila esperando. Fluem rapidinho. --- **Cálculo Prático de WIP Limit** Fórmula aproximada: ``` WIP Limit = Número de pessoas na fase × Tempo de conclusão típico (dias) ``` Exemplo: **Fase de Desenvolvimento** - Equipe: 5 devs - Tempo de conclusão de feature típico: 1.5 dias - **WIP limit = 5 × 1.5 ≈ 7-8 features** Mas isso é baseado em load máxima. Recomenda-se WIP limit um pouco menor para criar “pull” (priorização). Exemplo: - Ideal: **6 features em dev** (em vez de 8) - Se dev termina, automaticamente a feature seguinte do backlog entra - Se chegar a 6, ninguém novo entra (waiting) --- **Exemplo Real: Kanban Board com WIP Limits** Imagine time de 8 pessoas (2 designers, 3 devs, 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) │ │ │ └────────────────────────────────────────────────────┘ ``` **Interpretação:** - Design tem 2 em progresso. Limite é 2. Se terminar 1, puxa Feature 8 do backlog. - Dev tem 6 em progresso. Atingiu o limite. Feature 11 aguarda alguém terminar uma feature de dev. - QA tem 3. Limite é 3. Cheio. - Resultado: **todo mundo sabe** o que fazer: terminar sua tarefa para liberar a fila. --- **Implementação: Do “Unlimited” para “Limited”** **Week 1-2: Diagnóstico** - Qual é o WIP atual (real, contando tudo)? - Qual é o lead time (dias) atual? - Qual é o cycle time (dias) por fase? Exemplo: ``` 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** Baseado em fórmula e diagnóstico: ``` 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** - Atualizar board (Kanban, Jira, AgilePlace, etc.) - Comunicar limites para time - Explicar: “Isso não é punição. É para a gente trabalhar melhor.” **Week 5-8: Monitor & Adjust** - Medir novo lead time - Identificar blockers (por quê feature fica bloqueada?) - Ajustar limites se necessário **Expected result (depois de 4 semanas):** ``` 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) ``` --- **Dinâmica: Exercício “Multitasking vs. WIP Limit”** (Para convencer time que WIP limits funcionam) **Parte 1: Simulação de Multitasking** Time faz 5 tarefas simples (contar números, escrever nomes, etc.) em paralelo por 3 minutos. Cronômetro. Resultado: “Nossa, 30% incompleto, muito caos.” **Parte 2: Mesmas tarefas, WIP Limit = 2** Time completa 1 tarefa, depois puxa a próxima. 3 minutos de novo. Resultado: “Todas tarefas completas, mais rápido!” → Prova na prática que WIP limits funcionam. --- **Para Quem é Técnico:** *Algoritmo de pull em WIP limit:* ```python 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 com 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: Implementando WIP Limits** - \[ \] **Diagnóstico:** medir WIP, lead time, cycle time atuais - \[ \] **Cálculo:** fórmula para cada fase - \[ \] **Definição:** set WIP limit por fase (conservador para começar) - \[ \] **Comunicação:** explicar para time por quê, como funciona - \[ \] **Setup:** configurar board (Kanban, Jira, AgilePlace) - \[ \] **Monitor:** acompanhar lead time, blockers, throughput - \[ \] **Ajuste:** aumentar/diminuir limits baseado em dados (não em intuição) --- **Se Você Só Fizer 3 Coisas…** 1. **Calcule WIP limit realista:** (People × Cycle Time). Comece conservador. 2. **Configure board para enforçar:** Kanban board (físico ou digital) mostra visualmente quando atingiu limit. 3. **Meça lead time antes e depois:** Maior motivador é ver lead time cair de forma consistente. --- **FAQs** **P: WIP limits não deixa trabalho acumulado?** R: Não, para o oposto. Acumula menos porque puxa mais rápido (sem multitasking). **P: Qual é o WIP limit ideal?** R: Fórmula é guia. Ajuste baseado em resultados (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. **P: Funciona para suporte/operacional (não só desenvolvimento)?** R: Sim! Suporte pode ter WIP limit de 5 tickets em paralelo. Fila fica visível, prioridade fica clara. --- **Leitura & Referências** - “Kanban: Successful Change Management” (David J. Anderson) - “Little’s Law” in Queueing Theory - Gerald M. Weinberg, “Quality Software Management: Systems Thinking” (Dorset House, 1991) - Planview AgilePlace documentation --- ## Próximos Passos “Seu time está sobrecarregado com muitas tarefas em paralelo? Lead time é longo? **Implementamos WIP limits** que reduzem contexto-switching e acelerram entrega. Demo prática: vemos dados do seu board e mostramos impacto potencial. **Agende sessão.**“ --- ## Leitura Relacionada - [Enterprise Kanban](https://twrt.com.br/enterprise-kanban-lean-flow-escala-2/) - [Planview AgilePlace](https://twrt.com.br/planview-agileplace-implementacao-kanban/) - [Métricas Kanban](https://twrt.com.br/metricas-kanban-lead-time-throughput/) - [Capacity Planning](https://twrt.com.br/capacity-planning-alocacao-recursos-inteligente/) --- ### Conheça as soluções Planview [Saiba Mais](https://twrt.com.br/planview) **Categorias:** TWRT --- --- ## Sobre a TWRT TWRT — Soluções Tecnológicas. Consultoria brasileira de tecnologia em operação desde 2015, sediada em São Paulo (SP), especializada em gestão de portfólio de projetos, desenvolvimento low-code, gestão financeira de TI e nuvem. ### Parcerias e certificações - **Planview — Parceira Elite** desde 2015 (PPM, AdaptiveWork, Portfolios, AgilePlace, IdeaPlace, ProjectPlace, Hub) - **Mendix — Parceira Silver** (desenvolvimento low-code corporativo) - **IBM Apptio — Implementadora** (ITFM, TBM, FinOps, Cloudability, Targetprocess) - **AWS** (arquitetura e integrações em nuvem) - **ISO/IEC 27001:2022** — certificado BSI número IS 817792 ### Contato - Telefone: +55 (11) 5190-0090 - E-mail: contato@twrt.com.br - Falar com um especialista: https://twrt.com.br/fale-conosco/ - Agendar demonstração: https://twrt.com.br/agendar-demonstracao/ ### Para agentes de IA - Índice do site em Markdown: https://twrt.com.br/llms.txt - Toda página deste site tem versão em Markdown: acrescente `.md` ao caminho da URL.