O que é Lead Time?

Lead time é um termo usado em diferentes áreas de operação e produção, sem criador único. No Método Kanban, a Kanban University enfatiza que o nome, sozinho, não especifica quais marcos estão sendo medidos. Em abril de 2023, atualizou sua definição de Customer Lead Time: passou do intervalo entre compromisso e entrega para o intervalo entre pedido do cliente e entrega.

Outras referências usam marcos distintos. O Kanban Guide de 2025 define Cycle Time como o tempo decorrido entre início e fim de um item conforme a Definition of Workflow. Essas definições não devem ser fundidas. O verbete privilegia o tempo vivido pelo cliente ao explicar Customer Lead Time e sempre explicita quando mede outra parte do fluxo.

Imagine pedir uma refeição e ouvir que o preparo levou dez minutos, embora você tenha esperado meia hora desde o pedido. Os dois tempos podem ser verdadeiros, mas respondem a perguntas diferentes. Lead Time é um intervalo entre pontos escolhidos do fluxo. Para entender a experiência do cliente, registre quando o pedido chegou e quando o resultado foi entregue. Para entender outra parte do sistema, escolha outros marcos e dê outro nome ou qualifique a medida.

Pedido e entrega. Na definição atual da Kanban University, Customer Lead Time começa quando o serviço recebe a solicitação do cliente e termina quando a atende. Se o pedido fica numa fila por cinco dias antes de ser aceito, esses cinco dias fazem parte da espera do cliente. A data em que o time assumiu o compromisso pode ser importante para gerir sua capacidade, mas não apaga a fila anterior. Se o pedido não chegou a um canal que o serviço reconhece, defina claramente quando a contagem começa.

Tempo decorrido. A medida inclui espera, trabalho ativo, bloqueios, revisão e qualquer outra passagem entre os marcos. Não é soma das horas em que alguém trabalhou diretamente. Se o item entra segunda-feira e é entregue na sexta, a equipe deve combinar se conta diferença entre datas, dias corridos, horas ou dias úteis. Métodos distintos dão números distintos; a consistência permite comparar a série. Para clientes, um prazo em dias corridos pode ser mais compreensível do que uma conta interna em horas de expediente.

Lead Time de partes do fluxo. Pode ser útil medir da priorização à entrega, do início de construção à homologação ou da submissão à aprovação. O termo genérico permite esses pares de marcos, mas a equipe precisa nomeá-los. Um tempo curto dentro de desenvolvimento não prova que o cliente recebe rápido se a demanda espera muito antes. Um tempo longo de análise pode refletir decisões não tomadas, não trabalho técnico lento. Os intervalos menores ajudam a localizar a espera maior, enquanto o total mantém a perspectiva de quem pediu.

Cycle Time. No Kanban Guide de 2025, Cycle Time mede o tempo decorrido entre o início e a conclusão de um item dentro da definição de workflow. O ponto de início pode ser o de compromisso ou outro escolhido pelo sistema. A relação entre Cycle Time e Customer Lead Time depende desses pontos. Se o pedido chega muito antes de o item começar, o primeiro pode ser menor que o segundo. O verbete Cycle Time aprofunda essa medida; não use os nomes como sinônimos sem conferir o que a ferramenta registra.

Pontos de compromisso e conclusão. Um quadro Kanban pode separar opções ainda não assumidas, trabalho comprometido e itens entregues. O marco de compromisso informa a responsabilidade do serviço, mas o cliente pode esperar antes dele. O marco de entrega também precisa ser real: mover o cartão para "concluído" enquanto falta publicar, avisar ou disponibilizar algo subestima a espera. Combine o que significa receber valor e torne a política visível. Para trabalho cancelado, registre um destino distinto; não trate cancelamento como entrega bem-sucedida.

Dados por item. Registre ao menos identificador, tipo de demanda, data do pedido e data de entrega. Se o fluxo permite, registre mudanças de estado e bloqueios para investigar causas. Dados manuais podem bastar no início, desde que sejam consistentes. Verifique registros faltantes, itens reabertos e migrações de ferramenta. Uma medição automática com marcos errados continua errada. Preserve mudanças de política para entender por que a série histórica mudou.

Distribuição, não só média. Dois serviços podem ter a mesma média e experiências muito diferentes. Um pode entregar todos os itens perto de dez dias; outro entrega metade em um dia e metade em dezenove. Histograma, percentis e gráfico de pontos mostram variação e casos longos. Para comunicar um prazo provável, descreva que parcela histórica dos itens semelhantes foi concluída até certo tempo. "85% dos pedidos desse tipo foram entregues em até 12 dias no período observado" é mais informativo que "leva 12 dias". O exemplo é de forma de comunicação, não promessa universal.

Segmentação. Compare itens da mesma classe de trabalho e política. Uma solicitação padrão e um incidente crítico podem ter tempos diferentes por desenho. Misturá-los pode produzir média que não representa nenhum dos grupos. Tamanho, dependências, canal e prioridade também importam. Segmentar demais, porém, deixa amostras pequenas e previsões frágeis. Escolha separações que mudam a decisão e informe quantos casos sustentam a leitura.

Expectativa de serviço. Uma Service Level Expectation usa dados históricos para expressar um tempo com probabilidade. Se o sistema muda, a expectativa precisa ser revista. Ela não é garantia para cada item. Ao combinar uma expectativa com o cliente, diga quais tipos de solicitação entram, qual é o marco inicial e como exceções serão tratadas. Quando o item atual envelhece perto do limite, o time pode investigar bloqueios antes de estourá-lo. A idade do trabalho em andamento complementa a análise de itens já entregues.

Melhoria do fluxo. Se Lead Time é longo, siga itens reais para ver onde esperam. Uma fila antes de aprovação pode pedir política mais clara ou capacidade reservada; um item grande pode precisar de divisão; excesso de WIP pode espalhar atenção. Não assuma que todo atraso se resolve pressionando pessoas a trabalhar mais horas. Reduzir etapas de controle sem entender seu papel também pode piorar qualidade. Escolha uma hipótese de mudança e compare distribuição, falhas e experiência do cliente depois.

Relação com outras métricas. Throughput conta itens concluídos por período; WIP mostra trabalho iniciado ainda aberto. A Lei de Little relaciona médias de WIP, vazão e tempo em condições específicas, mas não permite prometer prazo individual sem analisar variabilidade. O CFD ajuda a enxergar acúmulo. O hub de métricas ágeis reúne essas leituras. Lead Time continua sendo um resultado do sistema que precisa de contexto, não uma alavanca isolada.

Não jogue com o relógio. Uma equipe pode aparentar melhora mudando o início para depois da fila ou o fim para antes da entrega real. Também pode dividir trabalho em cartões mínimos sem verificar se a necessidade do cliente foi atendida. Documente definições, acompanhe qualidade e pergunte se o cliente percebeu a redução de espera. A métrica deve tornar problemas visíveis, não incentivar truques de classificação.

Leia tendências com cautela. Uma redução temporária após uma semana de horas extras não demonstra melhoria sustentável. Mudança de mix de trabalho, sazonalidade ou cancelamentos também podem alterar a série. Compare períodos com contexto e examine casos extremos. A equipe precisa de tempo para estabilizar uma nova política antes de inferir seu efeito. Se o tempo cai enquanto defeitos ou reaberturas sobem, revise a intervenção.

O valor da medida está na conversa que ela permite: o que o cliente espera, onde o sistema acumula trabalho e que compromisso é honesto fazer. Com marcos claros e dados suficientes, o time consegue testar melhorias e comunicar incerteza sem fingir precisão que não possui.

Produto digital. Imagine um time hipotético que recebe 20 pedidos de melhoria num mês. Uma solicitação chega no dia 1, é escolhida no dia 8, começa a ser construída no dia 10 e chega ao usuário no dia 18. Com diferenças simples entre datas, Customer Lead Time é 17 dias; o intervalo entre início de construção e entrega é 8 dias. Os números são ilustrativos. Reportar apenas os 8 dias faz a pessoa que pediu perguntar onde foram parar os outros 9. O time vê que a maior parte da espera ocorreu antes da construção e decide investigar priorização e preparo, não exigir mais velocidade de código.

O time registra outros itens e descobre uma distribuição ampla: alguns chegam em poucos dias, outros ficam semanas esperando uma decisão. Se a média for publicada sozinha, pode esconder a incerteza para pedidos novos. A equipe separa melhorias pequenas de integrações complexas, comunica marcos e acompanha itens abertos que envelhecem. Ela não promete que toda solicitação será resolvida no mesmo prazo, pois o histórico mostra variação.

Contratos. Imagine uma equipe jurídica que recebe pedidos de contrato. Antes, a área comercial considera que o prazo começou apenas quando o jurídico aceitou um pedido completo. O cliente, porém, espera desde o primeiro envio. Em um caso hipotético, o pedido passa 4 dias aguardando documentos, 3 em análise, 5 por aprovação e 2 por assinatura. O Customer Lead Time é 14 dias. O tempo de análise ativa é apenas uma parte.

A equipe decide mostrar a exigência de documentos antes do envio e criar uma conversa rápida para corrigir pedidos incompletos. A medida seguinte deve começar no mesmo marco anterior, senão parecerá que melhorou só porque a contagem mudou. Também acompanha devoluções por erro, para não encurtar prazo aceitando informação insuficiente. O objetivo é um contrato correto recebido mais cedo, não apenas uma fila interna menor.

Suporte. Imagine um serviço que resolve dúvidas simples e incidentes urgentes. Se somar todos os casos, uma média de 6 dias pode parecer aceitável, mas incidentes graves não podem esperar esse tempo e dúvidas simples talvez sejam resolvidas no mesmo dia. O grupo separa classes, define início na solicitação recebida e fim na solução confirmada conforme a política. Para incidentes, mede também tempo até restabelecimento; para dúvidas, observa reabertura. Os números do cenário são ilustrativos.

Esses contextos mostram por que um único Lead Time sem nome completo é insuficiente. A pergunta é sempre quem espera, por qual entrega e desde quando. Só depois de responder vale comparar resultados ou mudar o fluxo.

A diferença depende de declarar os marcos. Na terminologia atual da Kanban University, Customer Lead Time começa no pedido; no Kanban Guide de 2025, Cycle Time começa quando o item é iniciado no fluxo definido. Os intervalos podem coincidir se início e pedido forem o mesmo evento, mas isso precisa ser dito.

Cursos K21 recomendados