Cycle Time (Tempo de Ciclo): O Que É e Como Calcular

O que mede

Cycle time é o tempo entre o trabalho começar num item e ele ser concluído — tipicamente do momento em que um ticket entra em "Em andamento" (ou status equivalente) até o momento em que é marcado como concluído. Responde uma pergunta mais estreita do que "quanto tempo isso levou no total": exclui o tempo parado sem ser tocado no backlog, focando no período depois que alguém de fato começou a trabalhar nele.

Por que importa

Cycle time é um dos sinais mais claros de se um time está de fato acelerando ou desacelerando ao longo do tempo — uma linha de tendência importa mais aqui do que qualquer número isolado. Também está bem ligado ao WIP: times que assumem trabalho em andamento demais ao mesmo tempo quase sempre veem o cycle time esticar, já que a atenção se divide entre mais itens do que qualquer um consegue avançar no mesmo ritmo.

Também é o número que torna uma estimativa de roadmap honesta. "Isso deve levar uma semana" é um chute a menos que esteja embasado no que trabalho parecido de fato levou recentemente — cycle time, quebrado por categoria, é exatamente essa base. Um time que sabe que a mediana de cycle time pra uma feature típica é 4 dias consegue dar um compromisso com confiança de verdade por trás; um time que não sabe está estimando de memória, que tende a ser otimista.

Como calcular

Pra cada item concluído, subtraia o timestamp em que entrou em "Em andamento" do timestamp em que foi marcado como concluído, e então olhe a distribuição entre um conjunto de itens — mediana e média juntas, não só uma. Uma mediana diz o que um item típico experimenta; uma média sozinha pode ser puxada bem longe em qualquer direção por alguns itens que ficaram parados por semanas ou terminaram incomumente rápido.

Um exemplo rápido: 8 itens terminam numa semana, com cycle times de 4h, 6h, 8h, 10h, 14h, 20h, 30h e 180h — um item que ficou bloqueado por mais de uma semana. A mediana é 12h, uma leitura razoável de um item típico. A média, 34h, é puxada quase toda por esse item bloqueado sozinho — que é exatamente por isso que cycle time costuma ser reportado como mediana com a média do lado, não a média sozinha.

Uma armadilha comum

Quebrar itens grandes em pedaços artificialmente pequenos bem antes de começar o trabalho vai encolher o cycle time no papel sem o time de fato entregar mais rápido — o tempo total pra entregar o mesmo resultado não muda, só fica espalhado em mais tickets que cada um parece rápido individualmente. Cycle time é mais útil comparado contra o próprio histórico recente do time pra trabalho de tamanho parecido, não como um número absoluto pra minimizar a qualquer custo.

Como o moasy.tech calcula isso

O moasy.tech recalcula cycle time — mediana, média e tamanho de amostra — automaticamente a partir do que já sincroniza do Jira e Linear, quebrado pelas mesmas categorias configuráveis por time (Bug, Feature, Dívida Técnica, Toil, Risco) usadas em toda Flow Metrics, com tendência semana a semana pra uma variação no número ser uma tendência de verdade, não dois retratos comparados na mão.

Veja as outras métricas de fluxo no guia completo, ou a implementação inteira na página de Flow Metrics.

Perguntas sobre cycle time