WIP limits

A maioria dos squads não tem um problema de velocidade. Tem um problema de congestionamento. O trabalho se acumula em todas as etapas, o context switching se multiplica e os cycle times explodem sem que ninguém entenda o motivo. WIP limits são o mecanismo que evita isso: um teto para a quantidade de trabalho que pode estar em andamento em qualquer etapa do seu pipeline de entrega ao mesmo tempo. Quando configurados corretamente, forçam o fluxo e expõem gargalos antes que eles travem o sprint. Esta página cobre a definição, como medir a aderência, o que é considerado bom e como melhorar a disciplina de WIP do seu squad.

Principais conclusões

• WIP limits são tetos explícitos para o número de itens de trabalho permitidos em qualquer etapa ativa do fluxo em um determinado momento. Eles importam porque trabalho em progresso sem restrição é um dos preditores mais confiáveis de cycle times lentos, sprints não cumpridos e burnout no squad. Menos itens ativos significa conclusão mais rápida de cada um deles.
• Não existe uma fórmula universal para WIP limits, mas um ponto de partida amplamente usado é definir o limite de cada etapa em aproximadamente 1 a 1,5 vezes o número de players que trabalham nela. Um squad de quatro desenvolvedores na coluna "Em Revisão" pode definir um WIP limit de quatro a seis itens abertos. Ajuste com base nos dados de cycle time observados.
• O erro mais comum dos times é tratar WIP limits como metas aspiracionais em vez de restrições aplicadas. Definir um limite de cinco numa ferramenta e rodar rotineiramente com oito itens ativos anula completamente o propósito. O limite só funciona quando o squad trata uma violação como sinal para parar de começar e começar a terminar.
• O DevStats expõe dados de throughput e cycle time de issues automaticamente, conectando-se ao seu provedor Git e ao seu issue tracker, e entrega o sinal que você precisa para validar se seus WIP limits estão funcionando. Você pode fazer benchmark das métricas de fluxo do seu squad contra mais de 1.000 times de engenharia. Comece um trial gratuito e veja seus números em menos de dois minutos.

Definição de WIP limits

WIP limits (limites de trabalho em progresso) são restrições sobre o número de tarefas, histórias ou tickets que podem estar ativamente em andamento em uma única etapa do fluxo de trabalho do time ao mesmo tempo. São uma prática central no Kanban e estão sendo cada vez mais aplicados em Scrum e modelos híbridos de entrega.

Tecnicamente, um WIP limit é um teto por coluna ou por etapa: se a coluna "Em Desenvolvimento" tem um WIP limit de quatro, nenhum novo item pode entrar nessa etapa até que um saia. A relação entre WIP, throughput e cycle time é descrita pela Lei de Little: Cycle Time = WIP / Throughput. Reduzir o WIP reduz diretamente o cycle time médio quando o throughput permanece constante. Times que aplicam WIP limits de forma consistente tendem a entregar com mais previsibilidade, o que se traduz diretamente em confiança dos stakeholders e compromissos de entrega mais precisos. Você pode ver como isso se manifesta nos seus próprios dados pelo rastreamento de throughput do DevStats, que mostra quanto trabalho seu squad está concluindo ao longo do tempo.

Por que WIP limits importam para times de engenharia

Squads sem WIP limits tendem a acumular trabalho em todas as etapas ao mesmo tempo. Um player pega um ticket novo enquanto três outros aguardam revisão. Outro começa uma feature enquanto uma correção de bug espera pelo QA. O resultado é um fluxo que parece ocupado, mas se move devagar, com itens de cauda longa envelhecendo de forma invisível até explodirem um sprint. Rastrear o cycle time de issues no DevStats torna esse padrão visível antes que ele vire um problema recorrente que o squad não consegue explicar.

Na perspectiva de um líder de engenharia, o inchaço de WIP ameaça diretamente sua taxa de entrega no prazo, a capacidade do squad de responder a incidentes e a precisão das previsões de sprint. Quando há itens demais em andamento, o custo do context switching sobe e a carga cognitiva de cada player aumenta, contribuindo para o tipo de pressão sustentada que gera atrito. WIP limits se conectam às dimensões de eficiência e fluxo do SPACE framework: são uma restrição de processo que protege o foco individual enquanto melhora o resultado do sistema.

Medir a aderência ao WIP é o primeiro passo. O engineering manager então decide se a resposta certa é apertar os limites, reestruturar o fluxo ou resolver um problema de planejamento upstream. Os dados dizem onde olhar; o líder decide o que fazer.

Como medir a aderência aos WIP limits

Medir a aderência ao WIP significa rastrear com que frequência a contagem de itens ativos do seu squad ultrapassa o limite definido para cada etapa do fluxo, e por quanto tempo. Seu issue tracker (Jira, Linear, GitHub Issues) é a principal fonte de dados. Capture snapshots da contagem de itens por etapa em intervalos regulares, ou use diagramas de fluxo cumulativo para ver como o WIP evoluiu ao longo do tempo. Combinar isso com dados de cycle time de PR dá uma visão mais completa de onde o fluxo está quebrando, tanto na revisão de código quanto na entrega de issues.

Não existem DORA benchmarks padronizados especificamente para WIP limits, já que o limite certo varia pelo tamanho do squad, design do fluxo e tipo de trabalho. A tabela abaixo descreve o que os padrões de aderência sinalizam qualitativamente. Os benchmarks variam pelo tamanho do time, complexidade da base de código e modelo de release.

Você pode ver como as métricas de fluxo do seu squad se comparam com times semelhantes usando o recurso de benchmarks do DevStats, que posiciona seus dados de throughput e cycle time em contexto.

WIP limits na prática: um exemplo real

Uma VP de Engenharia em uma empresa SaaS de 45 pessoas percebeu que as taxas de conclusão de sprint caíram de cerca de 80% para menos de 60% ao longo de dois trimestres. Analisando os dados do issue tracker, ela viu que a etapa "Em Desenvolvimento" rotineiramente tinha de oito a doze itens ativos contra um limite declarado de cinco. Os players faziam context switching entre vários tickets, e a revisão de código estava acumulando porque ninguém estava livre para revisar enquanto também desenvolvia. Ela decidiu aplicar o WIP limit existente de forma rígida por um sprint, tornando-o uma regra bloqueante em vez de uma diretriz, e combinando isso com um standup diário de cinco minutos focado exclusivamente em desbloquear itens travados.

Após três sprints, o cycle time médio de issues caiu cerca de 30% e as taxas de conclusão de sprint se recuperaram para acima de 75%. Ela atribuiu a melhora não à mudança de ferramenta, mas à mudança de comportamento: os players pararam de começar trabalho novo e passaram a terminar o trabalho existente primeiro. Ela então usou os dados de throughput para recalibrar o WIP limit para quatro, o que correspondia melhor à capacidade real do squad após considerar a carga de revisão de código.

Como melhorar a aderência aos WIP limits

1. Defina limites com base na capacidade, não na preferência. Comece com um WIP limit igual ao número de players em uma etapa e ajuste com base no cycle time observado. Se o cycle time cai quando você aperta o limite, você encontrou o número certo. Use seus dados de sprint para validar se limites mais apertados melhoram as taxas de conclusão ao longo do tempo.
2. Torne as violações visíveis em tempo real. Configure seu issue tracker para sinalizar ou destacar visualmente quando uma coluna ultrapassa seu limite. Uma violação que ninguém vê é ignorada. O objetivo é tornar a restrição impossível de ignorar durante o dia de trabalho.
3. Trate uma violação como sinal para agir em conjunto, não para adicionar mais trabalho. Quando o WIP ultrapassa o limite, a resposta do squad deve ser tirar alguém de uma nova tarefa para desbloquear o item travado, não continuar começando. Isso exige um acordo explícito nas normas do time, não apenas uma configuração de ferramenta.
4. Monitore a revisão de código como indicador antecipado. Uma etapa de revisão acumulada é frequentemente o primeiro lugar onde os WIP limits quebram. Fique de olho nas suas métricas de revisão de código para filas crescentes: é geralmente onde o congestionamento começa antes de se espalhar para as etapas anteriores.
5. Revise os limites trimestralmente. O tamanho do squad, o tipo de trabalho e o ritmo de entrega mudam. Um WIP limit que funcionava para um squad de seis pode estar errado para um squad de dez. Reveja os números no início de cada trimestre e ajuste com base em dados reais de throughput, não em intuição.

WIP limits vs. capacidade de sprint

WIP limits e capacidade de sprint são conceitos relacionados, mas medem coisas diferentes: a capacidade de sprint é a quantidade total de trabalho que um squad se compromete a concluir em um sprint, enquanto os WIP limits restringem quanto desse trabalho pode estar ativamente em andamento em uma única etapa do fluxo ao mesmo tempo.

Use WIP limits para controlar o fluxo dentro de um sprint e métricas de precisão de planejamento para avaliar se seus compromissos de sprint são realistas desde o início.