Você já deve ter ouvido falar dessa métrica, o Cycle Time, também chamado de Tempo de Ciclo. No entanto, é comum encontrar diferentes definições para esse conceito, o que pode gerar confusão. Então, neste artigo, vou tentar apresentar os diversos conceitos aplicados a essa métrica, qual a definição adotada pela Kanban University e como você deverá lidar quando alguém apresentá-la.
“Cycle” Time em Métodos Ágeis
O conceito mais comum de tempo de ciclo quando as pessoas falam de métodos ágeis está relacionado ao tempo que um item passa em uma determinada etapa do fluxo de trabalho. Veja o quadro de mapeamento de fluxo abaixo. Ele é composto por três etapas: Refinamento, Construção, Avaliação e Entrega. Nós já vimos em outros textos, que o Customer Lead Time é o tempo desde que recebemos a demanda até a entrega do item. Por outro lado, se o objetivo for medir o tempo que um item permanece especificamente na fase de Construção ou Avaliação, utilizamos o Cycle Time.. A ideia é que cada etapa representa um ciclo, logo o Cycle Time representa o tempo que o item permanece dentro do ciclo.
A Kanban University, por outro lado, não utiliza essa nomenclatura. Em vez disso, ela define o tempo que um item permanece na etapa como Lead Time. Dessa forma, é possível medir o Lead Time de Refinamento, o Lead Time de Construção e, se necessário, até mesmo um Lead Time mais abrangente.
Cycle Time aplicado ao Scrum
Esse aqui não é tão comum, mas eu já vi sendo utilizado. Partindo da ideia de que a Sprint é um ciclo, o Cycle Time seria o tempo que leva desde o item começar a ser movimentado dentro da Sprint, até ele ser considerado entregue de acordo com a Definição de Pronto (Definition of Done – DoD) definida pelo time.
Se o time tem uma boa performance, consequentemente, o Cycle Time médio será menor do que o tamanho da Sprint. Por outro lado, se a performance for insatisfatória, esse tempo tende a ser maior.
Cycle Time na Engenharia de Produção
Durante muitos anos, utilizei o Cycle Time conforme mencionei na primeira seção deste artigo. Aliás, se você pesquisar, é bem provável que encontre alguns artigos meus tratando desse mesmo conceito. Depois, estudei o assunto mais a fundo e percebi que realmente não fazia muito sentido, pois uma etapa não é exatamente um ciclo. É apenas uma parte de um fluxo maior. Dessa forma, o conceito da engenharia de produção parece fazer mais sentido. Nesse contexto, o Cycle Time representa o tempo necessário para produzir uma unidade do produto. Ele é medido desde que começamos a trabalhar no item até sua entrega ao cliente.
Customer Lead Time: a visão do time e a visão do cliente
Na imagem acima, vemos que o Customer Lead Time (Tempo de Espera do Consumidor) leva em consideração o tempo de expectativa do cliente. Desde o momento em que ele fez o pedido, ele já está aguardando pela entrega. Para o time ou squad, essa métrica pode parecer injusta, já que muitas demandas ficam esperando em um backlog ou em uma ferramenta de tickets antes de serem trabalhadas.
Por outro lado, quando olhamos pela perspectiva do cliente, esse pensamento muda drasticamente. Por exemplo, pense na última vez que você ligou para sua companhia telefônica para reclamar de um problema ou pediu uma pizza para entrega. Você não contou o tempo a partir do momento em que o atendente pegou o carro ou o pizzaiolo começou a preparar os ingredientes. Seu relógio começou a contar a partir do momento em que fez o pedido.
Esse é o Customer Lead Time, pois mede a expectativa do cliente.
A relação entre Cycle Time e Customer Lead Time
O Cycle Time, por sua vez, não inclui o tempo que o item ficou no backlog. Ele começa a ser contado apenas quando a equipe inicia o trabalho no item. Dessa forma, o Customer Lead Time é sempre maior do que o Cycle Time, pois inclui o tempo que o item passou aguardando no backlog / ferramenta de tickets.
Resumindo:
- Customer Lead Time = Tempo total de espera do cliente.
- Cycle Time = Tempo real de trabalho no item.
A fórmula da Engenharia de Produção
Você leu a seção anterior e falou…
Porém nem tudo são flores, pois você também deverá ver o Cycle Time como uma fórmula:
O Tempo de Produção Líquido é o tempo decorrido desde o momento em que começamos a trabalhar no item até concluirmos o trabalho. Logo, essa é a definição de Cycle Time que utilizamos na seção anterior.
Mas porque cargas d’água essa fórmula aparece? A fórmula da Engenharia de Produção é amplamente utilizada justamente porque, em muitos casos, não é viável contar individualmente o tempo de construção de cada item. Imagine uma fábrica de parafusos que fará milhares deles em poucas horas. Não dá para contar o tempo de um por um. Logo, o que se faz é ligar a linha de produção, produzir milhares de parafusos e contabilizar quantos foram criados naquele período. Esse, por sua vez, normalmente não é o caso do trabalho do conhecimento, onde um item pode levar dias para ser entregue.
A Posição da Kanban University
Não há. Ela nunca tocou no assunto Cycle Time. Se você tiver os livros de Kanban do David Anderson ou acesso às ferramentas dela, pode pesquisar e você não acha esse conceito lá. Na verdade, para eles tudo é um lead time. Os pontos de início e término que você utilizará dependem da necessidade que seu time / squad tenha.
Comparando os conceitos
| Conceito | Definição | Ponto de Início | Ponto de Término | Principais Características | Exemplos de Uso |
|---|---|---|---|---|---|
| Cycle Time em Métodos Ágeis | Tempo que um item permanece em uma determinada etapa do fluxo de trabalho | Quando o item entra em uma etapa (ex: Construção) | Quando sai da etapa | Cada etapa é tratada como um ciclo independente | Medir eficiência do fluxo em cada etapa |
| Cycle Time no Scrum | Tempo que um item leva dentro de uma Sprint | Quando a equipe inicia o trabalho no item dentro da Sprint | Quando o item é entregue e atende a Definição de Pronto | Mede a eficiência da equipe durante a Sprint | Avaliar se a equipe consegue entregar dentro da Sprint |
| Cycle Time na Engenharia de Produção | Tempo necessário para produzir uma unidade de um produto | Quando o trabalho no item começa | Quando o item é entregue ao cliente | Considera o tempo desde o primeiro esforço até a entrega | Melhoria da execução do trabalho |
| Cycle Time como fórmula (Engenharia de Produção) | Tempo médio para produzir cada unidade | Tempo total líquido de produção | Dividido pelo número de unidades produzidas | Usado quando não é possível medir individualmente cada unidade | Fábricas que produzem itens em massa |
| Cycle Time segundo a Kanban University | Não reconhece esse conceito; considera tudo como Lead Time | Não definido | Não definido | Em vez de Cycle Time, usa “Lead Time de Construção”, “Lead Time de Avaliação”, “Downstream Lead Time” etc. | Gestão de fluxo de trabalho baseada em Lead Time |
Qual os conceitos que as ferramentas utilizam sobre Cycle Time
Quando olhamos para como as ferramentas implementam a métrica de Cycle Time, percebemos que a maioria utiliza o conceito da engenharia de produção. Os exemplos são:
- Azure Devops (configurável)
- Business Map
- Broadcom Rally (configurável)
- ClickUp
- IBM ALM
- Jira
Algumas outras utilizam o conceito da engenharia de produção, porém acabam facilitando uma interpretação dúbia e colocam em um mesmo gráfico o “Cycle” Time em Métodos Ágeis. Um exemplo é o Trello através do famoso plugin Nave.
Já o caso da Monday.com é a única que eu percebi que utiliza o conceito da fórmula da engenharia de produção.
Há também algumas que não utilizam o conceito explicitamente, mas você pode configurar a ferramenta para que ela represente aquele que você desejar. São os casos da
Conclusão
Em suma, vimos que não existe uma única definição sobre Cycle Time. A Kanban University preferiu nunca entrar nessa discussão e cada ferramenta, time ou squad acabou criando o seu. Particularmente, gosto muito da definição da Engenharia de Produção, sem a utilização da fórmula. Creio que ela faz uma boa separação entre o tempo total desde a chegada e o tempo efetivo de trabalho.
O mais importante ao trabalhar com Cycle Time é garantir que a equipe tenha clareza sobre qual definição está sendo adotada e qual problema está tentando resolver. Se o objetivo for otimizar o tempo de trabalho dentro de uma equipe, faz sentido seguir a abordagem da engenharia de produção, sem considerar o tempo em backlog.
No final, não há uma única definição correta, e cada time ou organização deve escolher a abordagem que melhor se alinha às suas necessidades e objetivos. O essencial é garantir consistência na aplicação da métrica para que as análises e otimizações sejam eficazes. Mais do que medir o tempo, é fundamental entender o impacto de cada definição e como ela pode ajudar na tomada de decisões estratégicas.
Ficou alguma dúvida ou tem alguma sugestão, me procure no linkedin.
Quer aprender mais sobre esse tema? Dá uma olhada nos nossos treinamentos de
Team Kanban Practitioner (TKP)
arrivederci
