Lead Time e Cycle Time

Estes termos são frequentemente confundidos. Aqui estão definições precisas:

Lead Time: O tempo total desde quando o trabalho é solicitado até ser entregue.

• Relógio inicia: Quando o cliente/stakeholder solicita o trabalho
• Relógio para: Quando o cliente recebe o valor

Cycle Time: O tempo desde quando o trabalho começa até ser finalizado.

• Relógio inicia: Quando alguém começa a trabalhar no item
• Relógio para: Quando o trabalho está completo

A relação:

Lead Time = Cycle Time + Tempo de Fila (espera antes do trabalho começar)

Lead time é o que os clientes se importam. Cycle time é o que a equipe controla diretamente. Ambos importam.

Lead time é a experiência do cliente. Eles pediram algo—quanto tempo até receberem?

Lead times curtos significam:

• Feedback mais rápido sobre ideias
• Capacidade de responder a mudanças de mercado
• Maior satisfação do cliente
• Vantagem competitiva

Medir lead time revela:

• O custo total das filas (frequentemente 80%+ do lead time é espera)
• Onde o sistema adiciona atraso
• Se as melhorias estão funcionando

A maioria das equipes subestima drasticamente seu lead time porque só veem o cycle time. "A funcionalidade levou 3 dias para construir" ignora as 3 semanas que ficou no backlog e a semana que esperou pelo deploy.

Cycle time é a eficiência interna da equipe. Quão rápido podemos completar o trabalho uma vez que começamos?

Cycle times curtos significam:

• Menos trabalho em progresso de uma vez
• Loops de feedback mais rápidos
• Troca de contexto mais fácil
• Entrega mais previsível

Medir cycle time revela:

• Quanta variação existe (pouca ou muita?)
• Quais tipos de trabalho levam mais tempo
• Se a equipe está ficando mais rápida ou mais lenta

A variação importa tanto quanto a média. Uma equipe com média de 5 dias mas faixa de 2-20 dias é menos previsível do que uma com média de 7 dias e faixa de 5-10 dias.

Rastreamento manual (início simples):

• Registre a data em que o trabalho entra em "Em Progresso"
• Registre a data em que o trabalho chega a "Concluído"
• Calcule a diferença

Ferramentas digitais: A maioria das ferramentas Kanban rastreiam isso automaticamente:

• Jira: Relatório de Tempo em Status
• Linear: Análises de cycle time
• Trello: Com plugins
• Azure DevOps: Gráficos de cycle time

O que rastrear:

• Tempos de itens individuais (para tendências e análise)
• Percentis (50º, 85º, 95º) em vez de apenas médias
• Divisão por tipo de trabalho (bugs mais rápidos que funcionalidades?)
• Tendência ao longo do tempo (melhorando ou piorando?)

Evite:

• Usar apenas médias (elas escondem variação)
• Incluir fins de semana nos cálculos sem pensar
• Misturar diferentes tipos de trabalho em uma métrica

Uma vez que você tem dados de cycle time, use-os para:

Previsão: "85% dos itens como este são completados em 8 dias. Estou confortável em dizer que teremos isso na próxima sexta."

Identificação de problemas: "Este item está em progresso há 12 dias. Nosso percentil 85 é 8 dias. Algo está errado—vamos investigar."

Validação de melhorias: "No último trimestre nossa mediana de cycle time era 5 dias. Neste trimestre é 4 dias. Nossas mudanças de processo estão funcionando."

Dimensionamento correto: "Funcionalidades grandes têm 3x a variação de cycle time das pequenas. Vamos dividir o trabalho em pedaços menores."

A percepção: Cycle time não é apenas um relatório—é uma ferramenta para tomar melhores decisões no momento.