WIP o que é? Como contar? Como controlar?

WIP é um item fundamental na gestão da criação de produtos/serviços. Por isso, é importante conhecê-lo e saber como tratá-lo para que ele não nos atropele durante o nosso trabalho.

O que é WIP

A definição de WIP (Work in Progress) traduz-se como trabalho em progresso e, por vezes, como trabalho em andamento. Indica todos os itens de trabalho em progresso no seu fluxo de trabalho. 

Item de trabalho

Para deixar claro, um item de trabalho é algo que, quando entregue ao seu cliente (interno ou externo), faz com que ele perceba que há entrega de valor. Tradicionalmente, as histórias de usuário são um exemplo de item de trabalho. Entretanto, algumas empresas utilizam outros modelos, como o job-to-be-done ou, simplesmente, uma descrição livre. 

Exemplos

História de usuário: Eu, enquanto Nara Nova Cliente, quero testar o produto com meus próprios dados por 14 dias para confirmar que ele funciona no meu cenário real.

Job-to-be-done: Quando estou avaliando uma ferramenta nova e já me decepcionei com uma demonstração bonita que não sobreviveu ao meu dia a dia, quero verificar o comportamento dela com os meus próprios dados, para não assumir o risco de assinar um contrato e descobrir a limitação só depois.

Descrição simples: Lançar o plano de teste gratuito de demonstração da ferramenta por 14 dias corridos.

Não são itens de trabalhos

Épicos

Você pode ter épicos que são histórias de usuário muito grandes que o time NÃO implementa diretamente, pois, antes de entrar no fluxo de trabalho, esse épico é fatiado em histórias de usuário. Essas, ao entrarem no fluxo de trabalho, se transformam em WIP.

Tarefas

Tarefas são itens menores que podem ou não ser utilizados pelos times para facilitar a construção ou entrega do item de trabalho. Por exemplo, para o item de trabalho descrito anteriormente, poderiam ser as seguintes tarefas: 1) acrescentar um campo na tabela com a data-limite do plano gratuito de demonstração; 2) selecionar as funcionalidades que ficarão disponíveis no plano gratuito de demonstração; 3) criar o e-mail comunicando o encerramento do período de avaliação; 4) criar a tela de cadastro do cliente para o plano gratuito de demonstração… 

Cada tarefinha é relevante para o time, porém, isolada, é irrelevante para o cliente. Uma tela de cadastro é necessária, porém, se ela não faz nada, não entrega valor. O campo na tabela com a data-limite também é importante, porém o cliente não escreverá comandos SQL para atualizá-lo. 

Nunca, jamais, em hipótese alguma, contabilize as tarefas como WIP, pois isso inflará o número desnecessariamente.

Tarefas no Jira

Uma observação é importante: alguns softwares de gestão de fluxo, como o Jira, utilizam a categoria “tarefa” no mesmo nível da história de usuário. Cada time acaba definindo o que seria essa “tarefa” e eu já vi várias. Certo time utilizava a “tarefa” como algo não diretamente relacionado ao produto/serviço, por exemplo, uma reunião com o cliente para levantamento de requisitos. 

Já outro time conceituava as tarefas como itens de natureza mais técnica: ver consulta X, que está muito lenta; atualizar o framework Y, que está muito defasado e comprometendo a segurança da aplicação etc. Embora eu discorde que até itens técnicos possam ser escritos no formato de história de usuário: “Eu, enquanto Cliente Fulano, desejo que, ao buscar X, a consulta me responda mais rapidamente para que eu não desista da compra.”. “Eu, enquanto Cliente Beltrano, desejo acessar uma aplicação segura para que os meus dados não sejam vazados na internet.”.

Particularmente, sempre achei que isso confundiu mais do que ajudou, criando uma categoria sem conceito definido. Então, se a sua ferramenta tem essa particularidade, entenda que as tarefas são, na verdade, subtarefas. Dê uma olhada nesse artigo para ver as diferenças entre Product Backlog: Épico, História de Usuário e Tarefas.

Fluxo de Trabalho

O fluxo de trabalho é o conjunto de todas as etapas necessárias para construir, evoluir ou manter um produto pelo qual o seu time é responsável.

Aqui temos um fluxo de trabalho que começa em “Opções” e termina em “Entregue”. Esse fluxo de trabalho descreve a cadeia de valor dos produtos/serviços que o time entrega.

A primeira etapa

A primeira etapa do fluxo recebe inúmeros nomes, dependendo do time: Solicitações, Chamados, Product Backlog, Backlog, Opções, Piscinas de Opções, Lista de Espera etc. A primeira etapa é o local onde os itens chegam ao fluxo de trabalho: o Ponto de Recebimento de Demanda. Não necessariamente o time trabalhou neles; pode ser, inclusive, o recebimento de um tíquete ou de um e-mail de um usuário do produto/serviço.

A última etapa

A última etapa também tem vários nomes: Entrega, Delivery, Pronto, Entregue, Disponibilizado, Em Produção etc. É o momento em que o seu time entrega o incremento do produto ou serviço ao cliente, interno ou externo. O item nunca mais voltará às suas mãos, e qualquer mudança evolutiva ou corretiva resultará em um novo item. Esse é o Ponto de Entrega.

Ponto de Comprometimento

É o momento em que o time termina de analisar, avaliar o item e se compromete a criá-lo. É o ponto que separa o upstream do downstream.

Como contar o WIP

Após essa longa explicação sobre o que é e o que não é WIP, vamos ver como contá-lo. Na prática, tudo o que está entre a primeira e a última etapa. Se houver investimento de esforço (trabalho, tempo, dinheiro) do seu time, esse investimento deve ser contabilizado como WIP.

Conta como WIP

Todos os os itens que:

Estão nas colunas de execução

No Brasil, tradicionalmente em gerúndio: refinando, construindo, desenvolvendo etc.

Estão nas colunas de espera

Aguardando para avançar para a próxima etapa. No Brasil, tradicionalmente no particípio: refinado, construído, desenvolvido etc. Em alguns casos, também pode aparecer no infinitivo: “A construir”, “A desenvolver”, “A entregar”, etc.

Itens bloqueados

Sim! Eles contam! O bloqueio acontece quando iniciamos um item de trabalho e, tardiamente, descobrimos que alguma pré-condição para a construção ou entrega dele não foi atendida. Por exemplo, a aquisição de um certificado digital, a autorização de um gestor etc. O bloqueio não pode ser uma bengala para deixar itens “largados” no fluxo de trabalho, pois, em algum momento, ele era o time mais importante que tínhamos para construir. Se há um bloqueio, deve haver alguém lutando para desbloqueá-lo.

Itens no Upstream

Em resumo, o Upstream é composto por etapas de análise do seu fluxo de entrega. É um momento em que você está decidindo se vale ou não a pena se comprometer com a entrega do item. Como há esforço do seu time, todos os itens aqui também contam como Work in Progress, mesmo que, ao final dessa análise, o resultado seja descartar o item e não se comprometer a construí-lo.

Logo, o WIP desse time é igual a:

Stream	Classificação	WIP
Upstream	Colunas de Execução	5
Upstream	Colunas de Espera	5
	Total no Upstream	10
Downstream	Colunas de Execução (não bloqueados)	9
Downstream	Colunas de Espera	16
Downstream	Bloqueados	2
	Total no Downstream	27
	Total no Fluxo de Trabalho	37

O maldito trabalho escondido

Outra coisa que muitos esquecem de contabilizar como WIP é o que eu chamo de “maldito” trabalho escondido. Tradicionalmente vêm com alguém pedindo algo no diminutivo: “Pode dar uma ‘olhadinha’ nisso aqui?”; “Poderia responder àquele ‘emailzinho’”; “Você teria cinco ‘minutinhos’ para me ajudar em tal coisa?”, “Nós teremos uma ‘reuniãozinha’ ‘rapidinha’ para …”. Não se engane. Esses “pedidinhos” costumam consumir muito, muito tempo. Em um mundo ideal, você deveria contabilizá-los como WIP e incluí-los no seu fluxo.

Infelizmente, nem sempre é possível. Uma saída é configurá-los como bloqueios nos itens do fluxo de trabalho, pois causam indisponibilidade na equipe. Você pode contabilizar o Tempo de Bloqueio (Blocked Time) por meio da técnica de Agrupamento de Bloqueios (Blocker Clustering). Aí você verá o verdadeiro impacto dos “diminutivos”.

Torne o trabalho escondido visível e contabilize-o como WIP. 

Não conta como WIP

Entregues (Última etapa)

Todos os itens já entregues (última etapa do seu fluxo). Se já foi entregue, não está mais “em progresso”. Agora, verifique se esse item foi realmente entregue. Se o item sai da mão do seu time, vai para outro e depois volta, não é entregue. Na verdade, isso é um indicativo de dependência externa. Entregue o item, vai para o cliente e nunca mais volta.

Solicitações/Backlog/Opções (primeira etapa)

As demandas recebidas não significam que estão automaticamente em progresso. Logo, os itens dessa etapa não podem ser classificados como WIP. São apenas opções que podem ou não ser iniciadas no fluxo de trabalho.

Em resumo, considera-se WIP tudo o que se encontra entre a segunda e a penúltima etapa do fluxo de trabalho.

Como controlar

Sendo realista. Uma pessoa nunca jamais estará fazendo duas coisas ao mesmo tempo. Toda vez que olho um quadro de mapeamento de fluxo (quadro kanban) e vejo uma pessoa com dois itens em paralelo, crio uma imagem dessa pessoa com 2 computadores, 2 teclados, 2 mouses e 2 monitores, cada mão realizando uma tarefa diferente. Se ela está com três, quatro, cinco itens em paralelo, ela deve ser um polvo. Tenha isso em mente.

Limitação do WIP

Você já viu algumas vezes. Um número que fica acima das colunas do quadro de mapeamento do fluxo (quadro kanban). Esse número não é apenas uma informação aleatória. É uma convenção, um acordo do time. 

Controlar WIP é muito menos sobre ferramenta e mais sobre combinar uma regra e SUSTENTÁ-LA. Na prática:

1. Escolha onde colocar o limite.

As três opções mais comuns são: 1) por coluna (cada etapa tem seu teto) conforme a imagem anterior;  2) por pessoa (cada um puxa, no máximo, N itens); ou 3) por sistema inteiro (o quadro todo comporta X itens). O limite por coluna é o mais usado porque expõe o gargalo. O limite por pessoa é o pior, porque otimiza a ocupação individual e a microgestão em vez do fluxo.

2. Defina o número inicial. 

Não existe fórmula, existe ponto de partida. Um chute razoável é o número de pessoas que atuam naquela etapa, ou o número menos 1 para forçar a colaboração. 

Outra abordagem: observe o WIP médio atual do time e reduza-o em 20%. O número certo aparece depois, acompanhado de dados.

3. Escreva a regra de parada. 

Limite sem regra é decoração. A combinação precisa ser explícita: quando a coluna estiver cheia, ninguém puxa um item novo, e quem ficou ocioso vai ajudar a destravar o que estiver mais próximo do fim. Sem essa segunda parte, o limite gera desconforto e o time o abandona na primeira semana.

4. Conte o que costuma ser ignorado. 

Item bloqueado continua sendo WIP. Colunas de espera (“pronto para teste”, “aguardando aprovação”) são WIP e, normalmente, é ali que o trabalho apodrece. Se essas filas não entram na conta, o limite é fictício.

5. Meça o efeito, não o cumprimento.

As métricas que importam são tempo de ciclo, envelhecimento dos itens em andamento (aging) e throughput. Se você baixou o WIP e o tempo de ciclo caiu sem comprometer a entrega, então funcionou. Se o throughput caiu junto, você apertou demais ou o gargalo está fora do time.

6. Ajuste por evidência e, sempre, para baixo primeiro.

Reduza o limite até começar a doer, observe onde a dor aparece, resolva o impedimento estrutural que ela revelou. Aumentar o limite deve ser a exceção justificada, não a saída padrão quando a pressão aumenta.

7. Evite subterfúgios

Já vi quadros em que a pessoa criava uma área para itens bloqueados. Como diría Pe. Quevedo: “Isso non exsiste”. Não existe “área especial” no quadro para servir de muleta e evitar o tratamento do problema. Se houver muitos bloqueios, trate a causa e não fique fazendo gambiarra para dar um “jeitinho”.

Controlar a entrada

Embora a limitação do WIP seja a prática mais comum para controle do WIP, ela não é a única. Uma forma super eficiente é o controle de entrada do item de trabalho no fluxo de trabalho. Vamos ver como fazer isso.

Cadência de reabastecimento

Em vez de puxar itens a qualquer momento, o time reabastece a fila a um ritmo fixo (por exemplo, uma vez por semana). Isso cria um limite natural, pois nada entra pela janela. Dá uma olhada no nosso artigo sobre essa cadência do Kanban: Como reabastecer o seu fluxo Kanban: Do backlog para o quadro.

Critério de entrada explícito

Um item só pode ser iniciado se estiver compreendido, sem dependências abertas e com o resultado esperado claro. A maior parte do WIP inflado vem de trabalho que começou cedo demais e travou no meio do fluxo.

Porta única de entrada da demanda

Enquanto houver pedidos chegando por conversa de corredor, por mensagem direta e por reunião, o WIP real será sempre maior que o WIP do quadro. Tornar visível o trabalho invisível já reduz o volume, pois expõe o custo. Todo item tem que entrar no fluxo por uma etapa específica e todo item que estiver sendo trabalhado tem que estar no fluxo. Ninguém entra pela janela (etapa intermediária). Ninguém passa pelo fluxo em modo fantasma.

Regra de troca

Para entrar algo novo, algo sai. Simples e brutalmente eficaz em contexto de pressão dos stakeholders. Chegou uma prioridade absoluta; o stakeholder tem que escolher o que vai parar.

Acelerar a saída

Não é mexer na última etapa, e sim no fluxo. Nesse artigo, escrevi sobre 5 formas sistêmicas de fazer isso. Além desses: 

Fatiar menor

Itens pequenos atravessam o sistema mais rapidamente e reduzem o WIP em unidades de tempo, mesmo sem mexer no limite. É o controle mais subestimado.

Swarming (enxame)

Mais de uma pessoa no mesmo item, especialmente na parte mais próxima do fim. Reduz WIP por definição, já que a equipe termina antes de começar outro. Todavia, é um esforço temporário utilizado para desbloquear ou dar andamento a itens “idosos” (aging alto) ou de extrema importância que estão no fluxo.

Gestão de idade (aging)

Monitorar há quanto tempo cada item está em andamento e agir no item mais antigo primeiro. O limite diz “quantos”; o aging, “quais”.

Resolver as causas

É normal que tenhamos problemas no fluxo de trabalho. Infelizmente nem tudo ocorre como esperado. Há times que resolvem apenas as consequências do problema sem nunca examinar as causas. Isso aplaca o problema até que ele ocorra novamente. Aqui estão algumas das soluções possíveis para os desafios que mais impactam no elevado WIP dois times 

Redução de dependências externas e handoffs

Cada passagem para outro time ou para outra pessoa fora do time cria uma nova fila de espera com prioridades distintas. Times que precisam fazer muitas trocas de responsabilidade (handoff) para entregar itens de trabalho tendem a ser extremamente lentos. Times com competências completas mantêm WIP baixo sem esforço de gestão.

Tratamento sistemático de bloqueios

Registrar o motivo do bloqueio, agrupar por causa e resolver as causas recorrentes. Bloqueio não pode ser tratado como um simples infortúnio. Ele é um agressor de WIP e trava o fluxo de trabalho.

WIP de portfólio

Se a organização mantém oito iniciativas simultâneas para três times, nenhum limite de quadro resolve. O controle precisa ocorrer no nível acima.

Na prática, o limite numérico funciona como sintoma exposto: ele mostra que existe um problema. Os itens acima são os que efetivamente resolvem. Times que só apertam o número, sem mexer em entrada, tamanho e dependência, acabam abandonando o limite em poucas semanas.

Conclusão

WIP não é um bicho de sete cabeças. É algo simples que pode ser controlado. Tal controle depende muito mais da vontade do time ou da empresa do que de alguma técnica ou ferramenta.

Qual o seu próximo passo?

Além de você ter muita coisa sobre Kanban e Gestão de Fluxo para ler aqui no blog da K21, você também pode dar um passo ainda mais firme no treinamento: Team Kanban Practitioner (TKP) ou Kanban System Design (KSD).