Limites de WIP: Como Defini-los no Kanban (Com Exemplos)

Os limites de trabalho em andamento (WIP) são uma das formas mais rápidas de melhorar a velocidade com que o trabalho flui por uma equipe. Basta definir um número acima de cada coluna no seu quadro Kanban, e a regra é simples: ninguém começa um novo trabalho se a coluna já está no seu limite.

Principais Fatos

• Equipes que aplicam limites de WIP relatam tempos de ciclo 2x mais rápidos do que aquelas sem limites, segundo uma pesquisa com praticantes da Kanban University (2023).
• A troca de contexto custa aos trabalhadores, em média, 23 minutos para se refocarem totalmente após uma interrupção, o que se agrava quando várias tarefas estão em andamento simultaneamente (Universidade da Califórnia, Irvine, 2023).
• A equipe de software média trabalha em 3 a 5 tarefas ativas por pessoa ao mesmo tempo, mas o pico de throughput normalmente é alcançado com 1 a 2 tarefas por pessoa (State of Agile Report, 17ª edição, 2024).

O Que São Limites de WIP?

Limites de WIP (work in progress, ou trabalho em andamento) são limites explícitos de quantos itens podem existir em um determinado estágio de um workflow ao mesmo tempo. Em um sistema Kanban, cada coluna do quadro representa um estágio, e o limite de WIP fica acima dessa coluna como um número. Quando uma coluna atinge seu limite, ninguém traz novo trabalho para ela até que algo avance.

O conceito vem diretamente da manufatura enxuta (lean), onde a Toyota usava um sistema chamado "cartões kanban" para controlar o fluxo de produção no chão de fábrica. A ideia era que a superprodução é desperdício, e o mesmo princípio se aplica ao trabalho de conhecimento: quanto mais coisas você começa sem terminar, mais lento tudo fica.

Os limites de WIP não dizem o que fazer em seguida. Eles dizem quando parar de começar coisas e começar a terminar as existentes.

Por Que Limitar o Trabalho em Andamento?

O argumento a favor dos limites de WIP se apoia em uma fórmula chamada Lei de Little, que afirma:

Tempo de Ciclo = WIP / Throughput

Em termos simples: se sua equipe tem 20 itens em andamento e conclui 5 por semana, o tempo médio de ciclo é de 4 semanas. Reduza o WIP para 10 itens e o tempo de ciclo cai para 2 semanas, sem que a equipe trabalhe mais.

A matemática parece boa demais para ser verdade, mas o mecanismo subjacente é real. Veja o que acontece sem limites:

A troca de contexto mata o foco. Toda vez que alguém pega uma nova tarefa antes de terminar uma antiga, paga um custo mental de troca. Esse custo não é trivial. Pesquisas da UC Irvine estimam mais de 20 minutos de foco perdido por interrupção. Multiplique isso por 3 a 5 tarefas simultâneas por pessoa e você consumiu silenciosamente boa parte de um dia de trabalho só em sobrecarga de transição.

Filas longas escondem problemas. Quando o trabalho se acumula em uma coluna, ele se torna invisível. Ninguém percebe que uma tarefa de revisão ficou parada por três dias, porque o quadro está tão cheio que o atraso não se destaca. Os limites de WIP expõem esses gargalos imediatamente. Se a coluna "Em Revisão" atinge seu limite, a equipe precisa conversar sobre por que os itens não estão avançando.

As métricas de fluxo refletem isso diretamente. Se você usa um diagrama de fluxo cumulativo, bandas largas nos estágios intermediários são uma assinatura visual de WIP alto. Bandas estreitas e paralelas significam que o WIP está sob controle e o trabalho está fluindo. A velocity no ágil também tende a melhorar assim que os limites de WIP estabilizam quanto a equipe se compromete por ciclo.

Como Definir Limites de WIP

Não existe uma fórmula universal que funcione para toda equipe. Mas estes passos dão um ponto de partida que você pode ajustar ao longo do tempo.

Passo 1: Conte a capacidade da sua equipe

Comece com o número de pessoas que trabalham em cada estágio. Uma coluna de desenvolvimento com 4 desenvolvedores pode lidar com mais itens simultâneos do que uma coluna de revisão com 1 ou 2 pessoas.

Uma regra inicial comum: 2 itens por pessoa por coluna. Então uma coluna de desenvolvimento com 4 pessoas começa com um limite de WIP de 8.

Passo 2: Observe seu WIP real atual

Antes de definir qualquer limite, conte quantos itens estão de fato em cada coluna hoje. Essa é sua linha de base. Se a coluna "Em Andamento" já tem 14 itens para uma equipe de 3 pessoas, você tem um retrato claro de por que o trabalho demora tanto para ser concluído.

Passo 3: Defina limites um pouco abaixo da sua média atual

Se seu WIP médio por coluna é 10, comece seu limite em 7 ou 8, não em 3. Um limite apertado demais causa mais transtorno do que resolve, especialmente no início. Você quer que a equipe sinta a restrição e reaja, não que se sinta paralisada.

Passo 4: Aplique o limite como gatilho de conversa, não como bloqueio rígido

Quando uma coluna atinge seu limite, o trabalho da equipe é se concentrar no item bloqueado e resolvê-lo antes de trazer qualquer coisa nova. É aqui que os limites de WIP mudam o comportamento da equipe. "Podemos ajudar a fazer esse item passar pela revisão?" se torna um hábito diário em vez de uma reflexão tardia.

Passo 5: Revise e ajuste a cada duas semanas

Depois de duas sprints ou duas semanas, observe seu gráfico de burndown e os dados de tempo de ciclo. Se os itens estão fluindo mais rápido, aperte os limites. Se a equipe se sente constantemente bloqueada, afrouxe-os um pouco. Os limites de WIP são um botão de ajuste, não uma regra gravada em pedra.

Limites de WIP por Coluna do Quadro

Aqui está uma tabela de referência para uma equipe de software típica usando um quadro Kanban de quatro colunas. Estes são pontos de partida, não prescrições.

Para uma equipe de 4 desenvolvedores, uma configuração inicial razoável é: A Fazer (sem limite), Em Andamento (6), Em Revisão (3), Concluído (sem limite). Isso evita que a coluna de desenvolvimento vire um gargalo e mantém a revisão enxuta.

Se sua equipe usa Scrum com sprints de duas semanas, você pode aplicar limites de WIP ao quadro de sprint da mesma forma. A lógica é idêntica, mesmo que o enquadramento seja diferente. A distinção entre Scrum vs Kanban não muda a matemática subjacente da Lei de Little.

Erros Comuns ao Definir Limites de WIP

Definir limites e ignorá-los. Um limite de WIP que as pessoas contornam não existe de fato. Se a equipe frequentemente burla o limite com "exceções", o limite não está sendo aplicado. Construa o hábito antes de construir o processo.

Aplicar um único número a cada coluna. Uma coluna de revisão com 2 revisores e uma coluna de desenvolvimento com 5 desenvolvedores têm throughputs completamente diferentes. Um tamanho único não serve para ninguém aqui.

Tornar o limite baixo demais rápido demais. Se você cair de 15 itens por coluna para 3 da noite para o dia, vai criar pânico e resistência. O aperto gradual dá à equipe tempo para adaptar workflows e revelar os problemas que o WIP alto estava escondendo.

Esquecer os bloqueios. Os limites de WIP contam itens bloqueados também. Se 3 das suas 6 tarefas "Em Andamento" estão bloqueadas por dependências externas, você só tem 3 espaços de capacidade real. Rastrear bloqueios separadamente ajuda a manter o retrato preciso.

Não ajustar para story points. Algumas equipes definem limites por contagem de itens, outras por story points. Se suas tarefas variam muito em tamanho (uma tarefa de 1 ponto ao lado de um épico de 13 pontos), conte por pontos para obter um retrato mais honesto da carga.

Benefícios dos Limites de WIP

Quando as equipes realmente aplicam seus limites, algumas coisas acontecem consistentemente:

O trabalho termina mais rápido. O tempo de ciclo cai porque os itens não ficam esperando. Quando a equipe só pode ter 5 coisas em andamento, cada um desses 5 itens recebe atenção diária.

Os gargalos se tornam visíveis imediatamente. Uma coluna que está sempre no limite está lhe dizendo algo. A equipe não pode ignorá-la porque ela está bloqueando tudo o mais.

As conversas da equipe melhoram. Os limites de WIP criam momentos naturais para perguntar "por que isso está parado?" em vez de deixar os atrasos se tornarem invisíveis. As daily standups ficam mais focadas na mesma pergunta: o que está bloqueando o progresso agora?

O planejamento se torna mais honesto. Quando a equipe vê uma coluna cheia, para de se comprometer com novo trabalho que não consegue lidar. O comprometimento excessivo cai, e a previsão melhora. Isso se conecta diretamente a como a velocity no ágil se estabiliza assim que o WIP está sob controle.

O estresse cai. De forma contraintuitiva, ouvir "você só pode trabalhar em 5 coisas" é menos estressante do que ouvir "termine todas essas 15". As pessoas sabem no que focar.

Perguntas Frequentes

O que é um limite de WIP no Kanban? Um limite de WIP é um número colocado acima de uma coluna do Kanban que restringe quantos itens de trabalho podem existir naquele estágio ao mesmo tempo. Quando uma coluna atinge seu limite, os membros da equipe precisam ajudar a resolver o trabalho existente antes de trazer qualquer coisa nova.

Como calcular o limite de WIP certo? Comece com 2 itens por pessoa em cada coluna, depois observe por duas semanas. Se o trabalho está fluindo e os tempos de ciclo estão melhorando, aperte o limite. Se a equipe se sente cronicamente bloqueada, afrouxe-o. Não existe um único número correto. O objetivo é encontrar a restrição que revela gargalos sem paralisar o throughput.

Os limites de WIP podem se aplicar fora do Kanban? Sim. Equipes Scrum aplicam limites de WIP a quadros de sprint. Até equipes que usam métodos híbridos ou listas de tarefas simples podem se beneficiar de um limite informal de quantas coisas cada pessoa lida ao mesmo tempo. A lógica subjacente, a Lei de Little, se aplica a qualquer sistema de filas.

O que acontece quando um limite de WIP é atingido? A equipe para de trazer novo trabalho para aquela coluna e se concentra em resolver os itens existentes. Na prática, isso frequentemente significa se concentrar em uma tarefa bloqueada ou fazer uma revisão improvisada para desbloquear alguém adiante no fluxo. O limite cria urgência sem exigir a intervenção de um gestor.

A coluna "A Fazer" deve ter um limite de WIP? Geralmente não, ou pelo menos não um rígido. A Fazer funciona como um backlog. Um limite flexível (como 2x a capacidade da sprint) pode evitar que a coluna vire um depósito de itens, mas um limite rígido tende a criar urgência artificial em itens que ainda não estão prontos para serem trabalhados.

---

Os limites de WIP são uma pequena mudança com um efeito desproporcional no fluxo da equipe. Assim que você vê um gargalo aparecer pela primeira vez porque uma coluna atingiu seu limite, o mecanismo faz sentido. A partir daí, é só uma questão de ajustar os números. Acompanhe seus tempos de ciclo com um diagrama de fluxo cumulativo e observe o que acontece com as bandas quando o WIP diminui.