Lead time e cycle time como indicadores de previsibilidade

Por que lead time e cycle time medem previsibilidade

Previsibilidade, em um contexto de entrega de software, é a capacidade de estimar com boa confiança quando um item de trabalho ficará pronto, com base em evidências do desempenho recente do fluxo. Dois indicadores centrais para isso são lead time e cycle time. Eles não medem “velocidade” de pessoas; medem o comportamento do sistema de trabalho (fila, capacidade, interrupções, retrabalho, dependências) e, por isso, são úteis para acordos de prazo, planejamento e gestão de risco.

Em termos práticos, previsibilidade melhora quando: (1) a variação do tempo de entrega diminui, (2) o sistema tem limites de trabalho em progresso (WIP) e (3) o tamanho dos itens é mais consistente. Lead time e cycle time permitem enxergar exatamente esses pontos: o tempo total até entregar e o tempo efetivo em que o item esteve “em execução”.

Conceitos: lead time, cycle time e tempo de espera

Lead time

Lead time é o tempo decorrido entre um marco de início “do ponto de vista do cliente” e o momento em que o item é entregue (ou considerado pronto para uso). O marco inicial pode variar conforme o objetivo do indicador, mas precisa ser definido de forma objetiva e repetível.

• Exemplo de início: “item selecionado para desenvolvimento” (commitment) ou “solicitação criada” (request).
• Exemplo de fim: “implantado em produção”, “disponível para o usuário”, “feature flag habilitada”, ou “aprovado e pronto para release” (se sua entrega é por lote).

Lead time é o indicador mais próximo do que stakeholders sentem: “quanto tempo leva para eu receber o que pedi?”.

Cycle time

Cycle time é o tempo em que o item esteve efetivamente em execução dentro do fluxo, normalmente a partir do momento em que o time começa a trabalhar nele até o momento em que termina. Ele exclui parte do tempo de espera anterior ao início do trabalho, dependendo da definição adotada.

Continue em nosso aplicativo

Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.

ou continue lendo abaixo...

Baixar o aplicativo

• Exemplo de início: “em desenvolvimento” (primeiro estado ativo).
• Exemplo de fim: “pronto” (done), “em produção”, ou “pronto para release”.

Cycle time é útil para entender eficiência do processo e gargalos internos: revisões, testes, filas de validação, dependências técnicas, etc.

Tempo de espera (queue time) e por que ele importa

Uma forma prática de relacionar os dois é: lead time = tempo de espera + cycle time (simplificando). O tempo de espera inclui filas antes do início e também esperas entre etapas (por exemplo, aguardando code review, aguardando ambiente, aguardando aprovação).

Em muitos times, o maior componente do lead time é o tempo de espera, não o tempo “mão na massa”. Isso explica por que aumentar esforço individual raramente melhora previsibilidade; reduzir filas e variação costuma ter impacto maior.

Escolhendo marcos operacionais sem ambiguidade

Para que lead time e cycle time sejam indicadores confiáveis, os marcos de início e fim precisam ser definidos de modo que duas pessoas diferentes cheguem ao mesmo resultado ao medir o mesmo item. Evite marcos subjetivos como “quando começamos a pensar” ou “quando ficou quase pronto”. Prefira eventos registrados em ferramentas ou logs.

Definições comuns e quando usar

• Lead time (request-to-delivery): início em “solicitação criada” e fim em “entregue”. Útil para medir experiência do solicitante e acordos de prazo com áreas de negócio.
• Lead time (commit-to-delivery): início em “selecionado/comprometido” e fim em “entregue”. Útil para medir previsibilidade a partir do momento em que o time assume o trabalho.
• Cycle time (start-to-finish): início no primeiro estado ativo (ex.: “em desenvolvimento”) e fim em “pronto/entregue”. Útil para otimização interna e identificação de gargalos.

Uma regra prática: se a pergunta é “quando o cliente recebe?”, use lead time. Se a pergunta é “quanto tempo o time leva quando está trabalhando?”, use cycle time.

Como lead time e cycle time viram indicadores de previsibilidade

Previsibilidade não é só média: é distribuição

Para previsibilidade, a média sozinha é insuficiente. Dois fluxos podem ter média de 10 dias, mas um deles pode variar entre 2 e 30 dias, enquanto o outro varia entre 8 e 12. O segundo é muito mais previsível.

Por isso, use percentis e não apenas média:

• P50 (mediana): metade dos itens entrega em até esse tempo.
• P85: 85% dos itens entrega em até esse tempo (bom para compromissos com folga).
• P95: usado quando o custo de atraso é alto e você quer ser conservador.

Ao comunicar previsibilidade, uma frase operacional é: “Com base nos últimos N itens, 85% foram entregues em até X dias”. Isso é mais honesto e útil do que “leva em média X dias”.

Estabilidade e janela de dados

Previsibilidade depende de o processo estar relativamente estável. Use uma janela recente (por exemplo, últimos 30 a 90 dias ou últimos 20 a 50 itens), e revise sempre que houver mudanças relevantes: reorganização de time, alteração de política de revisão, mudança de arquitetura, sazonalidade de incidentes, etc.

Separar por classe de serviço e tipo de trabalho

Itens diferentes têm comportamentos diferentes. Misturar tudo em um único número pode destruir a utilidade do indicador. Separações comuns:

• Classe de serviço: urgente (expedite), padrão, data fixa.
• Tipo: bug, feature, dívida técnica, melhoria interna.
• Tamanho: pequeno/médio/grande (ou por faixas de pontos, se existirem).

Exemplo: bugs urgentes podem ter cycle time curto (prioridade alta), mas aumentar o lead time de features ao gerar interrupções. Separar as classes ajuda a enxergar esse trade-off.

Passo a passo prático: medir lead time e cycle time

Passo 1: defina o item de trabalho e o “fim” de entrega

Escolha uma unidade que represente valor entregue e que seja rastreável: ticket, issue, user story, change, pull request (em alguns contextos). Defina o que significa “entregue”:

• Se você faz deploy contínuo: “em produção” pode ser o fim.
• Se você libera por janela: “pronto para release” pode ser o fim, mas então você está medindo previsibilidade até ficar pronto, não até o usuário receber.

Evite trocar o marco final no meio da série histórica; se precisar, crie uma nova série.

Passo 2: defina o “início” para lead time e para cycle time

Escolha marcos que existam no seu fluxo real e que sejam registrados. Um modelo comum:

• Lead time (commit-to-delivery): início em “selecionado” (quando entra no WIP do time) e fim em “entregue”.
• Cycle time: início em “em desenvolvimento” (primeiro estado ativo) e fim em “entregue”.

Se seu fluxo tem mais de um estado ativo (desenvolvimento, revisão, teste), o cycle time deve cobrir todos os estados entre início e fim, inclusive esperas internas, porque elas fazem parte do tempo de execução do sistema.

Passo 3: colete timestamps e calcule durações

Para cada item, registre:

• timestamp de início do lead time
• timestamp de início do cycle time
• timestamp de fim

Calcule as durações em dias corridos ou horas. Para previsibilidade percebida por stakeholders, dias corridos costuma ser mais adequado. Para otimização interna, horas úteis pode ser útil, mas exige cuidado com calendários.

lead_time = fim - inicio_lead_time  (em dias ou horas) cycle_time = fim - inicio_cycle_time

Se houver reabertura (ex.: voltou de QA para dev), defina política: ou você mede até a primeira vez que ficou “pronto” (e trata reabertura como defeito do processo), ou mede até a entrega final (mais alinhado ao cliente). O importante é consistência e transparência.

Passo 4: limpe dados e trate outliers de forma explícita

Outliers não devem ser apagados automaticamente, porque muitas vezes são sinais de risco sistêmico (dependências, bloqueios, incidentes). Em vez disso:

• Marque itens bloqueados e registre motivo (dependência externa, ambiente, aprovação, etc.).
• Separe itens “expedite” (urgentes) em outra classe.
• Revise itens gigantes (épicos disfarçados) e quebre em itens menores para próximas medições.

Se você precisar de uma visão “típica” para comunicação, use mediana e percentis, que são menos sensíveis a outliers do que a média.

Passo 5: gere distribuição e percentis (P50, P85, P95)

Com a lista de lead times e cycle times, ordene os valores e calcule percentis. Você pode fazer isso em planilha ou script. Exemplo conceitual:

dados_ordenados = sort(dados) P50 = valor_na_posicao(0.50) P85 = valor_na_posicao(0.85) P95 = valor_na_posicao(0.95)

Use o mesmo método de percentil sempre (há variações em planilhas). O objetivo é consistência para acompanhar tendência.

Passo 6: transforme percentis em compromissos e SLAs internos

Uma aplicação direta de previsibilidade é criar um “SLE” (expectativa de nível de serviço) baseado em percentil, por exemplo:

• SLE de lead time: “85% dos itens padrão serão entregues em até 12 dias”.
• SLE de cycle time: “85% dos itens padrão completarão do início do desenvolvimento até entrega em até 7 dias”.

Isso não é uma promessa absoluta; é uma expectativa baseada em histórico. Quando o sistema muda, o SLE deve ser recalibrado.

Exemplo prático completo (com números)

Suponha que você coletou os lead times (em dias corridos) dos últimos 20 itens padrão comprometidos e entregues:

Lead times (dias): 4, 5, 5, 6, 6, 7, 7, 7, 8, 8, 9, 9, 10, 10, 11, 12, 12, 14, 18, 22

Interpretação:

• P50 (mediana) fica entre o 10º e 11º valores (8 e 9), então ~8–9 dias.
• P85 em 20 itens aponta para perto do 17º valor: 12 dias.
• P95 perto do 19º valor: 18 dias (ou 22, dependendo do método).

Como indicador de previsibilidade, você pode comunicar:

• “Metade dos itens entrega em até ~9 dias.”
• “Para compromisso com boa confiança, use 12 dias (P85).”
• “Casos raros podem levar ~18+ dias; investigaremos causas típicas desses atrasos.”

Agora observe o cycle time dos mesmos itens:

Cycle times (dias): 2, 2, 3, 3, 3, 3, 4, 4, 4, 4, 4, 5, 5, 5, 6, 6, 7, 7, 9, 10

Se o lead time P85 é 12 dias e o cycle time P85 é 6–7 dias, isso sugere que uma parcela relevante do tempo total está em espera (antes de iniciar ou entre etapas). Isso direciona ações: reduzir filas, limitar WIP, acelerar revisões, melhorar disponibilidade de ambientes, etc.

Diagnóstico: o que observar quando a previsibilidade piora

1) Aumento de variabilidade (cauda longa)

Quando P95 cresce muito mais do que P50, você tem uma “cauda longa”: poucos itens muito atrasados. Isso costuma indicar bloqueios, dependências externas, itens grandes demais ou trabalho interrompido por urgências.

Ação prática: marque e categorize motivos de atraso nos itens acima do P85 e procure padrões. Exemplo de categorias: “dependência de outro time”, “aguardando aprovação”, “incidente”, “retrabalho por bug”, “mudança de escopo”.

2) Cycle time estável, lead time piorando

Isso geralmente indica aumento de fila antes do início (mais demanda do que capacidade) ou WIP alto. O time trabalha no mesmo ritmo quando começa, mas demora mais para começar.

Ação prática: reduzir WIP, melhorar política de pull, revisar priorização e tamanho de lote. Se houver muitos itens “selecionados” parados, o marco de início do lead time pode estar cedo demais; ajuste para refletir compromisso real.

3) Lead time estável, cycle time piorando

Isso pode indicar gargalos internos: revisão mais lenta, testes demorados, instabilidade de ambiente, aumento de retrabalho, ou itens mais complexos.

Ação prática: medir tempos por etapa (dev, review, QA, deploy) e identificar onde o tempo cresceu. Se possível, medir também “tempo em bloqueio” por etapa.

4) Melhorou a média, mas piorou o P85

Isso pode acontecer quando você acelera alguns itens (por exemplo, urgências) e deixa outros esperando mais. A média cai, mas a previsibilidade para o trabalho padrão piora.

Ação prática: separar classes de serviço e proteger capacidade para o fluxo padrão, limitando urgências e definindo política clara de expedite.

Boas práticas para tornar lead time e cycle time acionáveis

Trabalhe com políticas explícitas de “pronto para começar” e “pronto para terminar”

Se o início do cycle time é “em desenvolvimento”, defina o que precisa estar verdadeiro para mover um item para esse estado: critérios mínimos, dependências resolvidas, descrição suficiente, etc. Isso reduz re-trabalho e interrupções que aumentam variação.

Reduza tamanho de lote para reduzir variação

Itens grandes tendem a ter maior variabilidade. Uma prática simples é estabelecer um limite: se um item não consegue ser concluído em poucos dias na maior parte das vezes, ele provavelmente está grande demais. Quebrar em fatias menores aumenta a frequência de entrega e melhora a previsibilidade dos percentis.

Use WIP como alavanca de previsibilidade

Mesmo sem entrar em detalhes de mapeamento, a relação é direta: quanto mais itens simultâneos, mais espera e mais alternância de contexto, aumentando lead time e variabilidade. Defina limites por etapa ou por time e trate violações como sinal de risco.

Monitore por cadência e com perguntas operacionais

Em vez de olhar números isolados, faça perguntas recorrentes:

• O P85 de lead time do trabalho padrão subiu ou desceu nas últimas 4–8 semanas?
• Quais foram os 5 itens mais lentos e por quê?
• Quanto do cycle time está em revisão/teste versus desenvolvimento?
• O volume de urgências está corroendo a previsibilidade do fluxo padrão?

Essas perguntas conectam o indicador a decisões: ajustar políticas, negociar capacidade, melhorar automação, reduzir dependências.

Armadilhas comuns e como evitar

Confundir lead time com esforço

Um item pode ter cycle time alto por complexidade real, mas também pode ter cycle time alto por espera em revisão ou por retrabalho. Sem separar causas, é comum atribuir o problema a “produtividade”. Evite usar esses indicadores para avaliação individual; isso incentiva manipulação de status e degrada a qualidade dos dados.

Medir “até pronto para QA” e chamar de entrega

Se o valor só chega ao usuário em produção, medir até um estado intermediário cria falsa previsibilidade. Se você precisa de um indicador interno, nomeie corretamente (ex.: “tempo até pronto para validação”) e mantenha lead time real até entrega.

Alterar definições sem versionar

Se você muda o marco de início ou fim, os números deixam de ser comparáveis. Quando precisar mudar, mantenha duas séries por um período ou registre a mudança como “versão do indicador”.

Usar apenas média e ignorar percentis

Média é facilmente distorcida por poucos casos extremos e não comunica risco. Percentis permitem negociar prazos com clareza: “P85” é uma forma prática de incorporar incerteza.

Aplicações diretas: como usar para planejar e negociar prazos

Previsão de prazo para um item

Se um item é “padrão” e semelhante aos anteriores, você pode usar o P85 do lead time como prazo com boa confiança. Exemplo: se P85 = 12 dias, e o item entra hoje no marco de início do lead time, a data provável (com ~85% de chance, dado histórico) é hoje + 12 dias.

Previsão para um conjunto de itens (planejamento de curto prazo)

Para um conjunto pequeno, uma aproximação simples é usar o throughput histórico (itens entregues por semana) junto com lead time percentil para validar se o sistema comporta a demanda. Se o throughput é 5 itens/semana e você precisa entregar 20 itens, isso sugere ~4 semanas de trabalho, mas o lead time P85 ajuda a calibrar o risco de cada item e a necessidade de reduzir tamanho ou dependências.

Gestão de risco com base na cauda (P95)

Quando o custo de atraso é alto, use P95 como referência de risco: “Se cair na cauda, pode levar até ~18–22 dias”. Isso permite planejar mitigação: dividir item, remover dependências antes de iniciar, reservar capacidade de validação, etc.