O que é WIP?
Em português: Trabalho em progresso · Também conhecido como: Work in Progress, trabalho em andamento, limite de WIP, WIP limit, Work in Process
WIP é todo o trabalho que já começou e ainda não terminou. Limitar o WIP é o jeito mais direto de fazer o time terminar mais e começar menos.
WIP (Work in Progress), ou trabalho em progresso, é o conjunto de itens de trabalho que já foram iniciados e ainda não foram entregues, descartados ou abortados. No Kanban, o limite de WIP é a regra explícita que define quantos itens podem estar em andamento ao mesmo tempo, em cada etapa ou no fluxo inteiro.
Origem
A ideia de limitar o trabalho em andamento nasceu na manufatura. No Sistema Toyota de Produção, desenvolvido por Taiichi Ohno a partir dos anos 1950, os cartões kanban funcionavam como uma autorização para produzir: sem cartão livre, ninguém fabricava mais peças. O estoque entre as etapas ficava limitado por construção, e os problemas apareciam em vez de se esconderem atrás de pilhas de material.
A matemática por trás disso veio da teoria de filas. Em 1961, John D. C. Little publicou a prova da relação que ficou conhecida como Lei de Little: em um sistema estável, a quantidade média de itens em andamento é igual à taxa de entrega multiplicada pelo tempo médio que cada item passa no sistema.
No trabalho do conhecimento, quem popularizou o limite de WIP foi David J. Anderson, que aplicou a ideia em times de software nos anos 2000 e a descreveu no livro *Kanban: Successful Evolutionary Change for Your Technology Business* (2010). Limitar o WIP virou uma das práticas centrais do Método Kanban, ao lado de visualizar o trabalho, gerenciar o fluxo e tornar as políticas explícitas.
Fonte primária: Kanban: Successful Evolutionary Change for Your Technology Business
Na prática
Pensa numa rodovia. Até certo ponto, colocar mais carros na pista aumenta o número de pessoas que chegam ao destino. Passou desse ponto, todo mundo anda mais devagar, e com a pista lotada ninguém chega. O trabalho de um time funciona igual: começar mais coisas não faz terminar mais coisas. Faz tudo demorar mais.
O que acontece quando falta
Sem limite de WIP, o trabalho em andamento tende a crescer sem parar. Tudo que chega é começado, porque dizer “agora não” parece falta de comprometimento. O resultado é o time de muitas “iniciativas” e poucas “acabativas”.
Cada pessoa alterna entre vários assuntos, cada item demora muito mais do que precisaria, a priorização perde sentido porque tudo já está em andamento e a previsibilidade desaparece. As métricas também pioram em cadeia: o lead time cresce, o throughput oscila e qualquer previsão de prazo vira aposta. Os stakeholders veem o quadro cheio e ouvem “está tudo andando”, mas nada chega. Com o tempo, a sobrecarga deixa de ser um problema de fluxo e vira um problema de gente: cansaço, retrabalho e desgaste.
Como o WIP e o limite de WIP funcionam
Pensa numa rodovia. Até certo ponto, colocar mais carros na pista aumenta o número de pessoas que chegam ao destino. Passou desse ponto, todo mundo anda mais devagar, e com a pista lotada ninguém chega. O trabalho de um time funciona igual: começar mais coisas não faz terminar mais coisas. Faz tudo demorar mais.
WIP é um fato, o limite é um combinado. O WIP é o que existe hoje no seu fluxo, uma contagem. O limite de WIP é uma política que o time decide: “nesta etapa cabem no máximo 3 itens”. Quando o WIP bate no limite, ninguém puxa trabalho novo para aquela etapa.
O que conta como WIP:
- Todo item de trabalho que já recebeu algum esforço do time e ainda não foi entregue, desde a primeira etapa depois do backlog até a etapa anterior à entrega. - Itens em execução (“desenvolvendo”, “testando”) e itens em espera (“desenvolvido”, “aguardando deploy”). - Itens bloqueados. Um item parado continua ocupando atenção, contexto e capacidade.
O que não conta: ideias no backlog que ninguém tocou, itens descartados ou abortados, itens já entregues e, principalmente, tarefas. WIP se mede em itens que entregam valor ao cliente, não nas tarefas técnicas que compõem cada item.
Tipos de limite. O mais comum é o limite por etapa, escrito no topo de cada coluna do quadro Kanban. Mas também existem limites para o fluxo inteiro, por pessoa, por tipo de trabalho ou por classe de serviço. Todos seguem a mesma lógica: criar um teto que obrigue a terminar antes de começar.
Por que o limite acelera a entrega. A Lei de Little mostra que, com a mesma capacidade de entrega, mais itens em andamento significam mais tempo para cada item ficar pronto. Some a isso a troca de contexto: cada pessoa que alterna entre cinco assuntos perde tempo reaquecendo a cabeça em cada um. O limite de WIP ataca as duas coisas de uma vez.
O limite transforma o fluxo em sistema puxado. Em vez de alguém empurrar trabalho para o time, o time puxa o próximo item quando abre espaço. Quando a coluna enche, a pergunta muda de “o que eu começo agora?” para “o que eu ajudo a terminar?”. É o lema que a comunidade Kanban popularizou: pare de começar, comece a terminar.
O limite também é um alarme. Uma etapa que vive no limite enquanto a seguinte está vazia mostra onde está o gargalo. Sem o limite, esse problema se esconde numa fila que cresce em silêncio.
E no Scrum? O Scrum Guide não fala em limite de WIP, mas os dois conversam bem. A Sprint limita quanto trabalho o time assume no ciclo, não quantos itens ficam abertos ao mesmo tempo dentro dele. Um time que começa os oito itens da Sprint no primeiro dia costuma chegar ao último com oito itens pela metade. Com limite de WIP dentro da Sprint, os itens ficam prontos um a um, o Product Owner pode liberar valor antes da Sprint Review e o risco de não cumprir a Meta da Sprint cai.
Segmente antes de interpretar números. Um limite de WIP é política do sistema observado; pode precisar de tratamento diferente para incidentes urgentes, trabalho padrão e itens com espera externa. Não use uma exceção silenciosa para cada pedido importante, pois o limite perde seu poder de revelar capacidade. Se a equipe abre espaço retirando cartões bloqueados do quadro, a contagem deixa de representar trabalho iniciado. Observe também idade dos itens: um WIP estável pode esconder um cartão parado enquanto outros passam rapidamente. Throughput e tempo de ciclo ajudam a verificar se uma mudança no limite melhorou o serviço. A Lei de Little relaciona médias de WIP, vazão e tempo sob condições adequadas, mas não determina um limite ótimo universal nem elimina variabilidade. Experimente um acordo explícito, acompanhe qualidade e previsibilidade e ajuste com as pessoas que operam o fluxo.
Exemplos de limite de WIP em três contextos
Time de software. Imagine um time de seis pessoas com 18 itens em andamento e uma entrega média de 5 itens por semana. Pela Lei de Little, cada item leva em média 18 dividido por 5, ou seja, cerca de 3,6 semanas do início ao fim. O time define limites por etapa: 4 em desenvolvimento, 2 em revisão, 3 em teste e 1 aguardando deploy, 10 no total.
Nas primeiras semanas, a coluna de revisão enche e trava o desenvolvimento. Parece que piorou. Mas o limite expôs algo que já existia: só duas pessoas revisavam código. O time passa a revisar em par e a coluna volta a andar. Com os mesmos 5 itens por semana e 10 em andamento, o tempo médio cai para cerca de 2 semanas, sem ninguém trabalhar mais horas.
Área jurídica, fora da tecnologia. Três advogados cuidam da revisão de contratos da área comercial, com 40 contratos “em análise” ao mesmo tempo. Cada um alterna entre dez documentos por dia e nenhum sai. Eles combinam um limite de 2 contratos por pessoa e uma fila visível com a ordem definida junto com o comercial. O resto espera fora do fluxo. A área comercial passa a saber quando cada contrato sai, e os urgentes deixam de furar a fila no grito, porque a regra para urgência também fica explícita.
Portfólio de iniciativas. Uma diretoria mantém 25 iniciativas estratégicas abertas, divididas entre três times. Todas “andando”, nenhuma terminando. Ao limitar o portfólio a 5 iniciativas simultâneas, o que no modelo Flight Levels corresponde a gerenciar o fluxo no nível estratégico, a diretoria é obrigada a escolher. As outras 20 continuam na lista de opções, mas não consomem gente, reunião nem atenção até abrir espaço.
Repara no padrão dos três casos: o limite não aumentou a capacidade de ninguém. Ele parou de desperdiçar a capacidade que já existia.
Como definir e usar limites de WIP no seu time
Mapeie o fluxo real
Desenhe as etapas que o trabalho percorre hoje, inclusive as de espera, do backlog até a entrega. Combine também o que é um item de trabalho para o time: algo que entrega valor ao cliente, não uma tarefa.
Conte o WIP de hoje
Some tudo o que está entre a primeira etapa depois do backlog e a entrega, contando itens em espera e bloqueados. Esse número costuma assustar, e é bom que assuste.
Comece com um limite possível
Defina limites um pouco abaixo do WIP atual, por etapa ou para o fluxo inteiro. Um ponto de partida comum é algo próximo do número de pessoas que trabalham na etapa. O objetivo do primeiro limite é gerar conversa, não acertar o número.
Deixe a política explícita
Escreva o limite no quadro e combine o que acontece quando ele é atingido: ninguém puxa item novo e quem está livre ajuda a destravar o que já está em andamento. Combine também a regra para urgências, para que elas não furem o limite sem critério.
Controle a entrada
O limite só funciona se o trabalho novo entrar por uma porta só. Faça reuniões de reabastecimento com quem demanda o time para escolher o que entra quando abre espaço.
Trate o limite atingido como sinal
Quando uma etapa vive no limite, pergunte por quê na reunião diária. Bloqueio externo, falta de habilidade no time, item grande demais? O limite mostra o problema, a conversa resolve.
Meça e ajuste em pequenos passos
Acompanhe lead time e throughput antes e depois. Ajuste os limites com dados, um de cada vez, e nunca para cima só porque incomodou.
WIP vs limite de WIP
| WIP | Limite de WIP | |
|---|---|---|
| O que é | A quantidade de itens em andamento agora | O teto combinado para essa quantidade |
| Natureza | Métrica, um fato | Política, uma decisão do time |
| Quem define | O próprio sistema de trabalho | O time, com quem demanda trabalho dele |
| Onde aparece | Na contagem do quadro e no CFD | Escrito no topo de cada coluna ou do fluxo |
| Exemplo | 20 itens entre o backlog e a entrega | Em teste: no máximo 3 itens |
Confundir os dois leva a um erro comum: achar que basta medir o WIP para melhorar o fluxo. Medir mostra o problema. Só o limite muda o comportamento, porque obriga o time a escolher o que termina antes de começar outra coisa. Para acompanhar o WIP ao longo do tempo, o Cumulative Flow Diagram é a visualização mais usada.
Erros comuns ao limitar o WIP
- Contar tarefas como WIP. Infla o número e esconde o que importa: quantos itens de valor estão parados no meio do caminho.
- Esquecer espera e bloqueio. Contar só o que está “em execução” faz o WIP parecer baixo enquanto o trabalho envelhece nas colunas de espera.
- Limite de enfeite. Um número no quadro que todo mundo fura “só dessa vez”. Se o limite nunca é respeitado, ele não existe.
- Limite alto demais. Se o time nunca bate no limite, ele não gera nenhuma conversa e não muda nada.
- Limitar o time e deixar a entrada livre. Stakeholders continuam empurrando trabalho por fora, e o limite vira fonte de conflito em vez de proteção.
- Usar o limite para cobrar pessoas. O limite existe para enxergar o sistema. Quando vira instrumento de pressão individual, as pessoas passam a esconder trabalho do quadro.
- Mexer no limite toda semana. Sem dados de lead time e throughput, o ajuste vira palpite.
Por que limitar o WIP importa para quem cuida de produto
Limite de WIP parece assunto de operação, mas mexe diretamente com três coisas que qualquer pessoa de produto persegue.
Tempo até o mercado. Menos itens em andamento significam menos tempo entre a decisão de fazer algo e o cliente poder usar. Cada semana que um item passa parado no meio do fluxo é uma semana de valor que ninguém recebe, o que se mede com o Custo do Atraso.
Aprendizado mais rápido. Produto se descobre com feedback de uso real. Um time com 20 coisas pela metade não aprende nada com nenhuma delas. Um time que termina uma de cada vez recebe feedback cedo e corrige a rota enquanto ainda é barato.
Previsibilidade honesta. Com o WIP estável, o lead time fica estável, e a pergunta “quando fica pronto?” passa a ter uma resposta baseada em dados, não em promessa. Isso muda a relação com stakeholders: em vez de negociar prazos no grito, o time mostra o histórico e combina expectativas.
E tem um efeito colateral que vale ouro: limitar o WIP obriga a escolher. Quando só cabem três coisas, alguém precisa dizer quais são as três mais importantes. Essa conversa sobre prioridade, que muita organização evita, passa a acontecer toda semana.
Visão K21
O que a gente aprendeu na prática sobre WIP
WIP é fato, limite é combinado. No post “Pare de fazer tanta coisa ao mesmo tempo: Limite o WIP”, o Avelino Ferreira Gomes Filho separa bem as duas coisas: o WIP é uma métrica concreta, e o limite é uma convenção sobre o volume de trabalho aceitável. Muita discussão improdutiva acaba quando o time entende essa diferença.
Tarefa não é WIP, e épico só vira WIP depois de fatiado. Em “WIP: o que é? Como contar? Como controlar?”, a regra é direta: nunca conte tarefas, porque isso infla o número. Um épico entra no fluxo como histórias menores, e são elas que contam.
Estoque de trabalho também deprecia. Como mostra o post “Métricas Ágeis comuns ao upstream, midstream e downstream”, o limite evita que uma etapa vire um grande amortecedor de trabalho parado. Todo estoque perde valor, inclusive o de trabalho do conhecimento: a análise feita há três meses já não reflete o mercado de hoje.
A falta de limite cobra um preço humano. Em “Burnout: o custo implacável da falta de limite de WIP”, o Avelino leva a discussão para a vida pessoal: trabalho, família, estudo e contas formam um quadro que ninguém mapeia. Como cada pessoa é uma só, o limite dela tende a ser um. Priorizar e sequenciar deixa de ser técnica de gestão e vira cuidado com a própria saúde.
Baseado nos posts: Pare de fazer tanta coisa ao mesmo tempo: Limite o WIP; WIP o que é? Como contar? Como controlar?; Métricas Ágeis comuns ao upstream, midstream e downstream; Burnout: o custo implacável da falta de limite de WIP
Para se aprofundar
No blog da K21
- Pare de fazer tanta coisa ao mesmo tempo: Limite o WIP
Por que limitar o WIP e como definir os primeiros limites, com um quadro de logística como exemplo.
- WIP o que é? Como contar? Como controlar?
O guia mais detalhado sobre o que entra e o que não entra na contagem do WIP.
- Burnout: o custo implacável da falta de limite de WIP
O custo humano de trabalhar sem limite, no time e na vida pessoal.
- Métricas Ágeis comuns ao upstream, midstream e downstream
Como contar o WIP em cada parte do fluxo, do upstream ao downstream.
Fontes primárias
- Kanban: Successful Evolutionary Change for Your Technology Business, David J. Anderson (2010)
- A Proof for the Queuing Formula: L = λW, John D. C. Little (1961)
- Toyota Production System: Beyond Large-Scale Production, Taiichi Ohno (1988)
Termos relacionados
Comparativos relacionados
Aprenda mais sobre os assuntos relacionados.
Perguntas frequentes
O que é WIP?
WIP é a sigla de Work in Progress, trabalho em progresso. São todos os itens de trabalho que o time já começou e ainda não entregou, incluindo os que estão em espera ou bloqueados. É uma das métricas centrais do Kanban, porque quanto mais itens em andamento, mais tempo cada um leva para ficar pronto.
Qual a diferença entre WIP e limite de WIP?
O WIP é uma contagem: quantos itens estão em andamento agora. O limite de WIP é uma regra combinada pelo time: quantos itens podem estar em andamento, no máximo, em cada etapa ou no fluxo inteiro. Medir o WIP mostra o problema. O limite é o que muda o comportamento.
Como definir o limite de WIP do meu time?
Conte o WIP atual, incluindo itens em espera e bloqueados, e comece com limites um pouco abaixo dele. Um ponto de partida comum é algo próximo do número de pessoas em cada etapa. Depois, ajuste aos poucos, olhando lead time e throughput. O primeiro limite serve para gerar conversa, não para ser perfeito.
Tarefas contam como WIP?
Não. WIP se conta em itens de trabalho que entregam valor ao cliente, como histórias de usuário. As tarefas técnicas que compõem cada item não entram na conta, porque inflariam o número e esconderiam quantos itens de valor estão realmente parados no fluxo.
Dá para usar limite de WIP no Scrum?
Dá, e ajuda bastante. O Scrum Guide não fala em limite de WIP, mas a Sprint limita o escopo do ciclo, não quantos itens ficam abertos ao mesmo tempo dentro dela. Limitar o WIP dentro da Sprint faz o time terminar itens mais cedo, em vez de chegar ao último dia com tudo pela metade.
O que fazer quando o limite de WIP é atingido?
Ninguém puxa trabalho novo para aquela etapa. Quem está livre ajuda a terminar o que já está em andamento: revisando, testando, destravando bloqueios. Se a etapa vive no limite, é sinal de gargalo, e a conversa sobre a causa deve acontecer na reunião diária do time.
