Delivery Planning Meeting no Kanban: como planejar as entregas

A Delivery Planning Meeting é a reunião do Kanban em que a equipe decide o que vai chegar ao cliente, quando e de que forma. Ela olha para a saída do sistema: itens que já estão prontos ou perto disso, janelas de implantação disponíveis, dependências de outras áreas e o que precisa ser comunicado a quem recebe o trabalho. É a reunião de planejamento de entregas do método.

Ela existe para resolver um problema conhecido de quem gerencia fluxo: a equipe começa a trabalhar num pedido e, no mesmo momento, alguém promete uma data ao cliente. Quando o trabalho atrasa, a promessa quebra e a confiança vai junto. A proposta do Kanban é separar as duas decisões. Começar a trabalhar é um compromisso; prometer uma data de entrega é outro, tomado mais tarde, com mais informação.

A seguir estão o lugar da Delivery Planning Meeting entre as cadências do Kanban, quem participa, a pauta, como usar dados para prometer datas e um exemplo para adaptar.

Onde a Delivery Planning Meeting entra nas cadências do Kanban

O Método Kanban, na linha da Kanban University, descreve um conjunto de reuniões recorrentes chamadas cadências. Entre elas estão a reunião diária do quadro (Kanban Meeting), a Replenishment Meeting, a Delivery Planning Meeting, a Service Delivery Review, a Operations Review, a Risk Review e a Strategy Review. A própria Kanban University insiste que as cadências não são sete reuniões novas para acrescentar à agenda: a ideia é ajustar reuniões que já existem para cumprir essas funções.

Segundo a Kanban University, o planejamento de entregas faz parte do método desde os primeiros anos e passou a ser ensinado como reunião separada para deixar explícita a separação entre o compromisso de atender um pedido e o compromisso com uma data. O panorama completo de todas as reuniões e da frequência de cada uma está no guia das cadências do Kanban.

Vale um esclarecimento: o Kanban Guide, a outra referência conhecida do método, não prescreve reuniões. Ele menciona a revisão frequente dos itens em andamento como prática comum, mas deixa a forma a cargo de cada sistema. Quem segue essa linha também precisa decidir entregas; só não tem um nome oficial para o momento em que isso acontece.

Replenishment e Delivery Planning: entrada e saída do sistema

As duas reuniões costumam ser confundidas porque ambas "planejam". A diferença fica clara quando se olha para o quadro:

A Replenishment trabalha antes do ponto de comprometimento, o momento em que um pedido deixa de ser opção e passa a ser trabalho aceito. A Delivery Planning trabalha perto do ponto de entrega. Como conduzir a reunião de entrada está em Replenishment Meeting: como reabastecer o backlog.

Quem participa e com que frequência

Não há lista fixa. O critério é reunir quem decide e quem é afetado pela entrega:

• Quem facilita o fluxo, papel que a Kanban University chama de gerente de prestação de serviço (Service Delivery Manager).
• Representantes da equipe que conhecem o estado real dos itens.
• Quem recebe e aceita a entrega: cliente interno, área de negócio, operação de TI, suporte, implantação ou logística, conforme o tipo de trabalho.
• Quem cuida de dependências: outras equipes, fornecedores, áreas de segurança ou de mudança.

A frequência acompanha o ritmo das entregas, e não o calendário de reuniões da empresa. Uma equipe que publica software toda semana tende a fazer a reunião semanalmente. Uma equipe que depende de janelas mensais de implantação faz a reunião antes de cada janela. Equipes que entregam continuamente, sem janela, às vezes juntam a decisão de entrega à reunião diária e só fazem uma Delivery Planning separada para entregas grandes ou arriscadas.

Pauta da reunião de planejamento de entregas

Uma pauta que funciona para a maioria dos contextos, em 30 a 60 minutos:

1. Revisar o que está pronto ou perto de ficar pronto. Partindo das colunas finais do quadro, listar os itens candidatos à próxima entrega.
2. Conferir o critério de pronto. Cada candidato passou pelos testes, pela homologação e pelas aprovações exigidas? Item que "está quase" não entra como certo.
3. Avaliar a previsão para os itens ainda em andamento. Para cada item que se quer incluir, qual a chance de ficar pronto até a data? Aqui entram os dados históricos, e não a opinião de quem está fazendo.
4. Mapear dependências e restrições. Janela de implantação, aprovação de mudança, disponibilidade do cliente para aceite, treinamento de usuários, comunicação.
5. Decidir o conteúdo e a data da entrega. Registrar o que entra, o que fica para a próxima e por quê.
6. Definir como a entrega será feita. Responsáveis pela implantação, plano de retorno se algo der errado, quem comunica o quê a quem.
7. Registrar e comunicar. O resultado vai para quem recebe a entrega e para a reunião diária, que passa a acompanhar os itens comprometidos.

O registro pode ser uma ata curta. A ata de reunião gratuita da Projeto Diário serve para guardar decisões, responsáveis e prazos de forma padronizada.

Como prometer datas com dados

A maior mudança que a Delivery Planning traz é trocar "acho que fica pronto na sexta" por uma previsão com probabilidade. Dois tipos de pergunta aparecem na reunião:

• Quando este item fica pronto? Responde-se com o histórico de tempo de ciclo da equipe: se 85% dos itens parecidos ficaram prontos em até 8 dias depois de começar, e o item começou há 3 dias, a data provável fica clara.
• Quantos itens cabem até a data? Responde-se com a vazão histórica, de preferência com simulação, que mostra intervalos de resultado em vez de um número único.

O passo a passo das duas técnicas, incluindo percentis do tempo de ciclo e simulação de Monte Carlo em planilha, está em previsão de entregas no Kanban. A regra prática para a reunião é simples: só prometa uma data quando a probabilidade for aceitável para o cliente, e diga qual é essa probabilidade.

Exemplo ilustrativo: equipe de sistemas de um hospital

Imagine, como exemplo ilustrativo, uma equipe que mantém os sistemas internos de um hospital e usa Kanban. As implantações em produção só podem acontecer na janela das terças-feiras à noite, depois de aprovação da área de mudanças.

Toda segunda-feira, às 10h, acontece a Delivery Planning Meeting com a coordenadora da equipe, dois desenvolvedores, o analista de infraestrutura, uma representante da enfermagem (principal usuária) e o responsável pela aprovação de mudanças.

• Itens prontos: um ajuste no relatório de ocupação de leitos e a correção de um erro no cadastro de pacientes, ambos homologados.
• Item em andamento: uma nova tela de prescrição. Pelo histórico, itens desse tamanho levam até 10 dias em 85% dos casos, e este começou há 4. A chance de estar pronto e homologado até terça é baixa.
• Decisão: entram os dois itens prontos; a tela de prescrição vai para a janela seguinte, com data comunicada à enfermagem já com essa margem.
• Como entregar: infraestrutura prepara o plano de retorno, a representante da enfermagem avisa as equipes de plantão sobre o novo relatório.

A enfermagem recebe uma data que provavelmente será cumprida, em vez de uma promessa otimista que quebraria na terça.

Erros comuns

• Prometer data na entrada. Se a data é fixada quando o trabalho começa, a Delivery Planning vira só uma confirmação de atraso.
• Fazer a reunião sem quem recebe a entrega. A equipe decide sozinha e descobre depois que o cliente não estava disponível para o aceite.
• Usar estimativa de esforço em vez de histórico. Opiniões sobre "quantos dias falta" costumam ser otimistas; o tempo de ciclo real é mais confiável.
• Repetir a reunião diária. A Delivery Planning não revisa todos os itens do quadro, só os candidatos à entrega e suas dependências.
• Não registrar o que ficou de fora. Itens adiados sem explicação geram a sensação de que a equipe esqueceu o pedido.

E se a equipe não usa quadro Kanban?

O princípio vale para qualquer forma de trabalho: separe a decisão de começar da decisão de prometer, decida entregas com quem as recebe e use o histórico de prazos da própria equipe, não estimativas otimistas. Uma equipe que trabalha com cronograma pode fazer a mesma reunião olhando para as atividades perto do término; uma equipe Scrum já tem a Sprint como janela, mas ainda precisa combinar com operação e clientes como e quando o incremento chega a eles.

Para começar na próxima semana

Escolha a próxima entrega da equipe e marque uma reunião curta com quem vai recebê-la. Use a pauta acima, leve o histórico de tempo de ciclo dos últimos meses e registre a decisão. Depois de três ou quatro ciclos, compare as datas prometidas com as datas reais: essa comparação mostra se a reunião está funcionando. Para dominar as cadências, as métricas de fluxo e o desenho do sistema como um todo, a formação em Kanban da Projeto Diário cobre o método do quadro às cadências, com dinâmicas práticas.