Uma dúvida comum em times que adotam Kanban é por que ele não possui uma “Sprint Planning”; não há um momento específico para que os itens saiam do Product Backlog e sejam colocados no quadro Kanban. O que fazer? Temos algumas opções que ajudam bastante.
Scrumban
Se o seu time utilizava Scrum e está adotando práticas Kanban, não se desespere. Um erro comum é achar que precisa jogar tudo fora para começar um novo método. Sinceramente, só faça isso se quiser ser demitido. Kanban é sempre evolucionário e mudanças abruptas causam muito mais dores do que benefícios. Então, se o seu time utiliza o Scrum e faz o Planejamento da Sprint (Sprint Planning), continue fazendo. Como os estadunidenses costumam dizer: “if it ain’t broke, don’t fix it” (se não está quebrado, não conserte).
Capacidade vs. Trabalho em progresso
Mas digamos que o seu time esteja começando sem o Scrum e você queira saber quando tirar itens do seu backlog e os trazer para o fluxo de trabalho mapeado no seu quadro Kanban.
A primeira coisa que você deve fazer é avaliar a capacidade do seu time e compará-la à quantidade de trabalho em progresso (Work in Progress – Wip). A ideia é simples, poderosa e frequentemente ignorada.
Nos quadros, é comum limitarmos a quantidade de itens de trabalho por meio do Limite de WIP.
Perceba que esse limite define a capacidade do time. Neste exemplo, ao olharmos para o quadro, o máximo de trabalho em progresso (WiP) é 6 + 8 + 5 + 4 = 23. Essa é a capacidade do time. Há inclusive uma métrica para isso chamada Nível de Ocupação (Occupation Level).
Nível de ocupação do time
No nosso exemplo, podemos dizer que, se o fluxo possui 23 itens, o sistema de trabalho está sob estresse. Qualquer chegada de um item urgente poderá resultar em sobrecarga. O ideal é que trabalhemos sempre com uma folga desejada. Por exemplo, 80% da capacidade: 18-19 itens. Se algo urgente chegar, mantemos o nosso fluxo saudável e sem grandes variações. Entretanto, tenha cuidado, pois excesso de folga também é ruim. Digamos que se o nosso fluxo atingir menos de 60% da capacidade (14 itens neste exemplo), podemos estar numa entropia em que nada novo chega e, na vida real, o backlog aumenta.
Backlog vazio
“Ah! O meu sistema está com excesso de folga, mas o backlog permanece sem novos itens.” Nesse caso, é muito provável que o backlog esteja na cabeça de alguém (cliente, usuário, gestor, reguladores, auditores) e não no documento que você chama de backlog.
O excesso de folga é um sinal de que o sistema de trabalho está em um estado de entropia (grandeza que mede o grau de desordem, aleatoriedade ou dispersão de energia em um sistema). E, como qualquer sistema nesse estado, segundo a Segunda Lei da Termodinâmica, tende a aumentar com o tempo, evoluindo naturalmente para estados de maior desordem e menor energia útil. Culminando no ponto de inanição (starvation) quando literalmente o seu time não tem nada para fazer. Neste nosso exemplo, digamos que esse estado corresponda a cerca de 40% da capacidade (9 itens).
Com isso concluímos que. Há capacidade para atender à demanda, então podemos incluir mais itens. Não há capacidade; não traga nada do backlog. Encher o sistema de itens de trabalho implica perda de desempenho, e não aumento.
Para reabastercer, não é só olhar o limite da primeira coluna após o backlog?
Volte para a imagem anterior. Veja que o limite de WiP da etapa de Planejamento Operacional, a primeira após a entrada de pedidos, que representa o backlog, é igual a 6 (seis). Nesse momento, ela possui apenas 5 (cinco) itens em progresso. Em uma conta básica, podemos fazer 6 – 5 = 1; assim, podemos incluir mais um item no nosso fluxo de trabalho. Porém, dê dois passos para trás e veja a imagem completa. Após essa etapa, todas estão no limite máximo. Trazer mais conteúdo ao fluxo só piora o resultado. Vejamos esse gráfico aqui embaixo.
Ele é bem simples e as etapas internas estão agrupadas no “Em Andamento”. Vemos que, a partir de junho de 2025, há um aumento muito significativo no número de novos itens que chegam ao backlog. Talvez, pressionado por isso, o time colocou mais itens “Em Andamento”, o que se observa no aumento da linha amarela a partir de setembro. A performance do time não melhorou. Pelo contrário, piorou muito. Veja que, após setembro, a linha de Concluído fica estagnada. Ou seja, nada é entregue.
Se removermos as áreas e mantermos as linhas, fica mais fácil perceber o problema.
Logo, se você olhar apenas para a primeira coluna após o backlog e ignorar o sistema, mais cedo ou mais tarde, o preço da performance será cobrado, e o custo poderá ser muito alto.
Posso, então, impedir que novos itens entrem no backlog?
É a mesma coisa que tentar segurar água com a mão. Vai escapar. Imagine que você cuide de um hospital e que o seu backlog seja as pessoas que chegam à recepção. Seria possível impedir a chegada de novos pacientes?
“Atenção, galera: estamos lotados. Está proibido ficar doente. Também ninguém mais pode sofrer nenhum tipo de acidente.”.
Essas frases são absurdas, e a mesma situação ocorre se você tentar impedir a entrada de novos itens de trabalho no backlog. Clientes têm necessidades, produtos apresentam defeitos e melhorias surgem. Seu time deveria ter capacidade para absorver a demanda, mas isso é papo para outro texto.
Reunião de Reabastecimento do Time (Team Replenishment Meeting)
Visto tudo isso, como o Kanban extrai itens do backlog e os coloca no fluxo de trabalho?
Assim como no Scrum, o Kanban tem uma cadência (reunião) para reabastecer o fluxo de trabalho. O nome dela é “Reunião de Reabastecimento do Time”. O objetivo dela é revisar o backlog e reabastecer o trabalho pronto para que seja puxado pela equipe.
Nela o time:
- Identifica itens prioritários do upstream.
- Prepara esses itens com definições suficientes para serem puxados quando houver capacidade.
- Garante que o time nunca fique ocioso por falta de trabalho.
Scrum vs. Kanban
Em uma primeira olhada, pode parecer muito com a reunião de Sprint Planning, porém há algumas diferenças entre os métodos.
Objetivo
A Sprint Planning compromete o time com um pacote fixo de trabalho que deve ser feito durante o período da sprint. Já a Team Replenishment repõe opções de trabalho, sem compromisso antecipado quanto à execução. Os itens ficam prontos para serem puxados quando houver capacidade.
Compromisso
O planejamento da sprint estabelece o compromisso coletivo do time com o trabalho a ser concluído no final daquele ciclo. Entretanto, no Reabastecimento do Time, o compromisso é apenas com a ordem e a prontidão, não com a entrega. Esta acontece quando o sistema permite
Obrigatoriedade
No Scrum, a Reunião de Planejamento da Sprint é obrigatória. No Kanban, a Reunião de Reabastecimento não é. Para ele, você só deve utilizar alguma reunião se ela for realmente necessária. “If it ain’t broke, don’t fix it”.
Papéis
No Scrum, há um facilitador chamado Scrum Master (SM). No Kanban, se o seu time tiver um SM, pode mantê-lo. Porém, se não tiver, ele não cria a figura de um “Kanban Master”, pois, para ele, qualquer um pode facilitar a reunião. Inclusive, no Kanban, é possível que ninguém assuma o papel de facilitador.
Além disso, o Kanban não desempenha o papel de Product Owner (PO). O que chega mais próximo disso é o Service Request Manager, mas não é a mesma coisa.
Opinião do Avelino e não do Kanban. Na prática, é muito difícil você ter uma boa reunião de reabastecimento sem um product owner e alguém que a facilite. As pessoas ficam divagando, e, no geral, os desenvolvedores não gostam de desempenhar as funções do PO (olhar números, conversar com clientes, ir para reuniões com gestores etc.) e tampouco de SM (estruturar reuniões, manter a conversa caminhando para o objetivo, garantir que apenas as pessoas relevantes estejam envolvidas etc.).
Quem participa da Reunião de Reabastecimento do Time
Todas as pessoas necessárias para definir a prioridade do item e determinar se ele está suficientemente refinado para entrar no fluxo de trabalho.
Pelo amor de Deus, não é a reunião que você chama um monte de gente que não deveria estar ali. Nada pior do que pitaco de pessoas que não têm “skin in the game” (não estão comprometidas) ou de pessoas que ficam em modo 2 de Paus ♣️ (naipe de baixo valor na maioria dos jogos de baralho). Elas estão ali de corpo, mas a mente está em outro lugar.
Periodicidade
A cadência pode ser por período (semanal, quinzenal…)
Conwip (Constant WIP)
Porém, essa reunião pode ser disparada por um gatilho. Veja a imagem abaixo:
Veja que a primeira coluna agora possui dois limites: 3 (três) e 6 (seis). O segundo é o Limite de Wip que já vimos. O primeiro é o limite mínimo e, toda vez que ele é atingido, dispara uma reunião de reabastecimento do time.
Esse sistema recebe o nome de Conwip (Constant WIP), em tradução livre, Trabalho em Progresso Constante. A ideia é que, ao limitar as etapas do fluxo em um mínimo e um máximo, você garante: 1) a quantidade de trabalho respeita a capacidade do sistema; 2) sempre há trabalho disponível para ser puxado; e 3) o sistema não entra em estado de entropia.
Reunião de Reabastecimento de Fluxo Interno (Internal Workflow Replenishment Meeting)
Esse palavrão (particularmente, não gosto do nome) ocorre em organizações que já estão em um nível mais alto de maturidade na adoção de Kanban (Nível de Maturidade 2 em diante). Nelas, olhamos o fluxo de ponta a ponta e não apenas no time, e, com isso, identificamos as dependências externas e alinhamos o fluxo entre os diversos times necessários para realizar a entrega ao cliente.
Objetivo
O objetivo dela é decidir quais demandas (itens) serão aceitas e as preparar para entrar no fluxo interno de cada time envolvido. Com isso, ela evita que cada time “otimize localmente” e quebre o fluxo global. A Internal Workflow Replenishment Meeting garante que vários times trabalhem como um único sistema, e não como ilhas competindo por prioridade.
Compromisso
É parecido com o da Reunião de Reabastecimento do Time. O compromisso NÃO é entregar trabalho, e sim manter a ordem e a prontidão do fluxo interno. Entretanto, há diferenças fundamentais entre elas. O Reabastecimento do Time é uma visão pontual. Cada um olha para a sua capacidade e faz a sua priorização. Já a Internal Workflow Replenishment Meeting define a ordem correta de passagem pelo sistema e a sequência entre as dependências. Podemos dizer, então, que os times fazem promessas locais. Já o sistema assume compromissos globais, e essa reunião cuida do compromisso do próprio sistema.
Obrigatoriedade
Assim como todas as cadências do Kanban, ela não é obrigatória. Para saber se você deve utilizá-la, responda duas perguntas:
- Hoje, nós temos algum problema que demanda algo como a Internal Workflow Replenishment Meeting? Mais uma vez: “if it ain’t broke, don’t fix it”.
- A segunda está relacionada à maturidade da organização: Hoje, é factível olharmos o fluxo de trabalho de ponta a ponta, chamarmos representantes para uma reunião e alinharmos os diferentes fluxos internos?
Se a resposta a alguma delas for não, não force a barra. Vai causar mais desgaste do que trazer benefícios.
Papéis
Se no Reabastecimento do Time não há obrigatoriedade de um facilitador, na Internal Workflow Replenishment Meeting é praticamente impossível não haver um. Muitas pessoas representam diversos interesses que podem ser antagônicos entre si. Um clássico exemplo são times de desenvolvimento que querem colocar novidades em produção o quanto antes e times de infraestrutura que desejam manter o ambiente estável e não querem disponibilizar novidades que possam comprometer a segurança desse ambiente.
Normalmente os facilitadores daqui estão no papel de Flow Manager ou Service Delivery Manager, pois são eles que respondem pelo fluxo de trabalho e os objetivos dele são:
- Manter a visão de ponta a ponta do fluxo para evitar otimizações locais que possam comprometer o sistema.
- Não defender backlog de um time.
- Cuidar do WIP, seus limites, gargalos e dependências
- Garantir a aplicação das políticas explícitas.
- Manter a reunião focada na decisão, não em um debate infinito.
Quem participa da Internal Workflow Replenishment Meeting
Como envolve vários times, algumas mudanças entre as pessoas que atendem a essa reunião são necessárias. Imagine um fluxo que envolva apenas dois times, cada um composto por cerca de 8 pessoas. Se todos forem à reunião, teremos, no mínimo, 16 pessoas presentes. Se forem três times do mesmo tamanho, já são 24 e por aí vai. O problema é que reuniões com muita gente são improdutivas. Logo é raro contar com times completos nessa também. No geral, vão os representantes dos times: Flow Manager, Service Delivery Manager, Service Request Manager, Product Owner, Scrum Master, Product Manager, Gerente de Projeto, líderes técnicos. Em resumo, pessoas que conhecem bem a realidade operacional e têm autonomia para negociar a ordem de trabalho.
Periodicidade
Eu adoro periodicidades pequenas, tipo semanal. Entretanto, nesse tipo de reunião, é muito, muito, muito difícil realizá-la de forma eficiente em um intervalo tão curto. É possível que ela funcione em um momento que exija muita atenção. Por exemplo, nos próximos 2 meses lançaremos o produto em escala nacional. Durante esse período realizaremos a Internal Workflow Replenishment Meeting semanalmente.
Fora isso, em casos raros, mas bons exemplos, ela acaba sendo quinzenal. A grande maioria é mensal mesmo. Já o disparo por gatilho em um sistema conwip, em tese, é possível, mas eu confesso que nunca vi para alinhar fluxos de diversos times.
Conclusão
Se, depois de tudo isso, você ainda acha que reabastecer o Kanban é apenas “puxar mais um item do backlog quando a primeira coluna tem espaço”, o problema não está no método, e sim na sua forma de enxergar o sistema. Kanban não é sobre manter as pessoas ocupadas; é sobre manter o fluxo saudável.
Sempre que você ignora a capacidade global, troca previsibilidade por ansiedade, entrega por ilusão de controle. Reabastecer bem não é sinal de frouxidão; é sinal de maturidade. Times imaturos lotam o sistema para parecerem produtivos; sistemas maduros criam folga para entregar. No fim das contas, Kanban não pergunta se você tem mais trabalho para começar; ele pergunta se você tem coragem de parar de começar coisas para, finalmente, terminá-las.
