Como calcular lead time em times de desenvolvimento

Sempre costumo dizer em meus treinamentos que “ágil não é bagunça”. A prova disso é a disciplina necessária para conseguir pôr em prática as 13 páginas do Scrum Guide, fora a quantidade de estudo que demanda as técnicas complementares como User Stories, Pair Programming, Kanban, Planning Poker e muito mais. Mas algo pouco debatido e muitíssimo importante é a parte de métricas ágeis do time.

Mas porque eu preciso de métricas em times ágeis?

Para que exista um plano de melhoria contínua concreto em execução junto ao time.

Sem métricas o time simplesmente pode rodar o ágil na sua forma mais básica, mas não estará melhorando continuamente o que é um grande risco. Estudiosos dos processos japoneses de manufatura, de onde o Lean surgiu (Toyota) e de onde o Scrum foi baseado, são categóricos em afirmar que todo processo enxuto de produção (logo os processos ágeis também) sofrem deterioração ao longo do tempo se não estão sempre em contínuo esforço de melhoria.

Ou seja, agilidade é uma jornada, não um destino.

Logo, se para me manter ágil devo sempre estar buscando a melhoria contínua e para que possa melhorar continuamente de maneira sustentável e assertiva, preciso de métricas. Afinal, o que não é medido não é gerenciado, como diria William Demming.

Isso fica ainda mais evidente quando você como Scrum Master full-time ou Agile Coach (meu caso) deve estar olhando para mais de um time ao mesmo tempo, mas não subestime o poder de ter métricas sob constante vigilância mesmo em times pequenos e avulsos.

Em artigo recente, falei de Velocity, e no artigo de hoje, vamos falar de outra métrica importantíssima, ou melhor, duas!

Você vai ver neste artigo:

1. O que é Lead Time e Cycle Time?
2. Lead Time no Azure Boards
3. Lead Time no Jira Software
4. Lead/Cycle Time Manual
5. E quando o Lead Time vai mal?

Vamos lá!

O que é Lead Time e Cycle Time?

Lead time na área de logística é o tempo total de um pedido ser feito por um cliente até o mesmo ser entregue a ele e a ideia aqui não é diferente. É uma métrica que geralmente está associada ao uso do Kanban e dá um pouco mais de trabalho para ser medida dependendo das ferramentas que você tem à disposição.

Basicamente o Lead Time é o tempo que leva de uma tarefa que foi criada no backlog até ela chegar no estado DONE ou seja, o tempo total de vida de um item de backlog (não necessariamente de desenvolvimento).

Já o Cycle Time (Tempo de Ciclo) é o tempo de desenvolvimento de uma atividade, ou seja, desde quando ela entrou em DOING/In Progress, até ela chegar em DONE, sendo sempre menor ou igual ao Lead Time.

Ambas métricas vão te dar um número de horas (ou dias, fazendo a conversão) para finalizar cada atividade, sendo que para o cliente, o que importa é o Lead Time (total, desde o pedido), mas para o time técnico, muitas vezes o foco é o cycle time.

Times ágeis devem sempre buscar quebrar seus itens de backlog em pedaços executáveis dentro de um espaço de tempo pequeno, o que pode ser obtido utilizando técnicas como DEEP, INVEST e SMART. Itens pequenos possuem menos risco e são mais fáceis de executar do que itens grandes e sim, mesmo problemas grandes e complexos podem ser quebrados em pequenas partes.

Obviamente “pequeno” varia de time para time, mas algumas boas práticas recomendam que o cycle time de uma User Story não seja maior do que uma sprint. Também podemos incluir nas boas práticas que o cycle time de uma tarefa (lembrando que uma história pode desmembrar em várias tarefas) não deveria levar mais do que um ou dois dias.

Assim, cravando alguns objetivos desejáveis ou apenas medindo o histórico vs situação atual, podemos analisar itens que possuam variações grosseiras de lead time e de cycle time e ajustar onde que está o problema no seu pipeline de desenvolvimento. Esse processo de melhoria contínua do Lead/Cycle Time é tema do famoso Improvement Kata da Toyota (onde o Cycle Time é chamado de Takt Time), onde objetivando chegar em uma visão ideal, partimos de uma condição atual para condições-alvo mais próximas rumo ao objetivo, aplicando PDCA a cada ciclo para melhoria.

A seguir vou lhe mostrar como medir o lead time nas duas ferramentas corporativas para gestão de projetos mais populares do mercado e também de como fazer isso manualmente, caso disponha de alguma ferramenta que não te forneça esta métrica e/ou faça na mão mesmo.

Lead Time no Azure Boards/DevOps

No Azure DevOps é possível ver todo o ciclo de vida de uma tarefa indo na aba History dela, como no exemplo abaixo.

Analisando o tempo entre a troca de estados da tarefa é possível perceber que o gargalo dela foi no Code Review, que demorou 15 dias para acontecer, contra apenas 2 dias de desenvolvimento e 2 de espera para entrar em desenvolvimento. Assim, temos um Lead Time de 17 dias e um Cycle Time de 16 dias.

É óbvio o problema aqui e onde devemos colocar nosso esforços, muito diferente do que apenas tentar melhorar a velocidade do programador em si, quando não é nisso que reside o problema.

Obviamente que analisar tarefa por tarefa não é uma tarefa muito prática e por isso é recomendada a instalação da extensão de Analytics no Azure DevOps, para ter à disposição aos widgets de Lead Time e Cycle Time que podem lhe ajudar muito nos seus dashboards.

No widget, você vê bem grande à esquerda o lead time atual (23 dias), o fluxo de valor usado na medição (da criação até DONE), o número de itens usados no cálculo (14 histórias e 1 bug) e o gráfico de controle em si onde cada bolinha representa um ou mais itens (itens entregues no mesmo dia aumentam a bolinha).

Se ficou curioso com a área cinza do gráfico (o desvio de padrão) e/ou calculou a média simples e teve um número diferente de 23 é justamente porque o Lead Time usa a mediana e não a média. Falo mais disso na seção de cálculo manual, neste mesmo artigo.

Apenas analise individualmente as atividades que tenham fugido grosseiramente do Lead/Cycle Time e que possam ser a razão de suas sprints não estarem rolando tão bem.

Lead Time no Jira Software

No Jira Software também temos como analisar o histórico de uma issue para entender no detalhe o que houve com ela, mas não é muito prático de fazer isso e é ainda mais trabalhoso que no concorrente da Microsoft, apenas em situações bem específicas você vai querer colocar uma “lupa” em apenas uma issue.

No geral, você vai usar a seção de relatórios no seu projeto do Jira, onde temos o Gráfico de Controle (Control Chart) que dá tanto a média comum quanto a mediana (bem mais realista, ignorando as discrepâncias) do Lead Time do time.

As bolinhas representam as entregas (issues DONE) ao longo do tempo e se tiverem muitas entregas juntas, ela pode ficar maior. Se você posicionar o mouse sobre a bolinha, vai ver o tempo exato que a issue levou para ser finalizada.

A linha vermelha é a média aritmética simples.

A linha azul escura é a média móvel e é mais útil que a anterior, pois é baseada no desvio padrão (área cinza) e desconsidera algumas discrepâncias (máximos e mínimos locais do gráfico). Se quiser entender melhor esse cálculo, confira a seção de cálculo manual mais adiante.

Logo abaixo do gráfico você tem como filtrar o período a ser plotado no gráfico. Sugiro desconsiderar períodos maiores que 3 meses ou a partir de algum marco importante pro time que tenha afetado drasticamente o seu processo. Além do período, você pode configurar para ele mostrar um tempo de ciclo (Cycle Time) específico (de um status x até um status y) ao invés do Lead Time inteiro.

Se quiser aprender a dominar estas e outras ferramentas do Jira, clique no banner abaixo!

Lead/Cycle Time Manual

Caso você não tenha à disposição uma ferramenta como o Azure DevOps ou o Jira Software e tenha de cuidar manualmente do Lead/Cycle Time do time, não desista, é possível e você tem duas maneiras de fazer isso.

Primeiro, a maneira 100% manual, no papel. Neste modo, você vai precisar imprimir um Lead Time Control Chart, como na imagem abaixo (no final do artigo você encontra para baixar), onde você tem as entregas no eixo x (horizontal) e o Lead Time (em dias) de cada entrega no eixo y (vertical).

A cada entrega DONE realizada, você avança na linha horizontal (é apenas uma sequência linear de entregas, busque a próxima linha vazia) e sobe na vertical buscando o número de dias que demorou para entregar esta demanda, fazendo um ponto preto na intersecção entre a linha dos dias e a linha da entrega, como mostra a imagem abaixo, onde uma demanda qualquer foi entregue em 4 dias.

Após várias entregas realizadas, você vai ter uma matriz de dispersão cheia de pontinhos, mostrando a tendência de tempo das entregas. O próximo passo é calcular a previsibilidade do time considerando o histórico do mesmo.

Para fazer isso, descubra o maior lead time do time, que na imagem abaixo é 9 dias e trace uma linha imaginária no lead time imediatamente inferior (8). O número de dias na linha de corte é o tempo médio (ponderado) de entrega do time.

Mas Luiz, teve entrega que demorou mais de 8 dias e entrega que demorou apenas 3 dias. É certo dizer que o time leva 8 dias?

Sim, mas com uma chance, uma probabilidade disso acontecer. Para calcular a confiança nessa previsão em %, conte quantos itens foram entregas na linha de corte e abaixo. Na imagem, temos 7 itens.

Depois, divida esse número de itens (7) pelo total de itens entregues, que nesse caso é 8 (tem apenas um item acima da linha de corte), o que nos dá 0,87 o que significa 87% de confiança que esse time entrega uma demanda comum em até 8 dias.

Bacana, não?

Mas e se o time tiver de entregar mais rápido, qual a chance de ser bem sucedido?

Movendo a linha imaginária para baixo, no lead time exigido para esta entrega, basta refazer o cálculo considerando o novo posicionamento da linha imaginária. Por exemplo, em 3 dias temos 12% de probabilidade de entregar uma demanda comum ou 50% de chances se tivermos apenas 7 dias para trabalhar na demanda.

Ao invés de usar o lead time control chart impresso, outra opção que você possui é registrar o lead das entregas no Excel ou Google Sheets e depois fazer só o cálculo manual da probabilidade (que eu não sei fazer automaticamente no Excel). Abaixo você confere uma imagem de como fica essa ferramenta, que eu disponibilizo para download no final deste artigo.

Nela, a coluna Lead Time calcula Fim – Início +1 (para arredondar para cima, tendo como 1 dia o lead time mínimo de qualquer demanda) e o gráfico gerado é uma matriz de dispersão, considerando a coluna Demanda como eixo x e a coluna Lead Time como eixo y.

Bem simples e prático. Na imagem acima, este time entrega em 5 dias com 70% de confiança.

Uma última dica: o time deve buscar uma confiabilidade de 85% nas suas entregas. Se estiver mais alto que isso, diminua a linha de corte. Se estiver abaixo disse, suba a linha de corte ou espere ter mais demandas entregues para o histórico fornecer uma boa amostragem para cálculo.

E quando o Lead Time vai mal?

A métrica de Lead Time, assim como todos os indicadores existentes, servem a um único propósito: provocar reflexão.

Assim, não tire nenhuma conclusão imediata ao ver a métrica de Lead Time ao final de uma sprint. Pare, pense, reflita, converse com o time. Se a métrica aparentemente está ruim, traga para uma retrospectiva, esse é um ótimo gancho para o time debater melhoria contínua e para, por exemplo, o Scrum Master identificar os principais gargalos que possam estar atrapalhando a produtividade time.

É importante frisar que o Lead Time é do time, e não de uma pessoa. Os problemas devem ser sempre analisados de maneira sistêmica e nunca apontando um dedo a alguém. Principalmente considerando que na maioria dos casos que tive a oportunidade de experienciar, o problema não era uma pessoa, mas comunicação, dependências, tecnológico, etc.

Mas Luiz, como eu posso conduzir esta análise em uma retrospectiva?

Se você conhece e possui o Diagrama de Fluxo Cumulativo (CFD, quero falar dele aqui outra hora), a análise sistêmica dos gargalos pode ser feita através dele. Mas vamos considerar para efeitos práticos que você não tem esta ferramenta ou não sabe usar.

Geralmente a análise do Cycle Time no detalhe se faz observando o histórico da issue no Jira Software ou Azure Boards. Mas como o Lead Time não é tão bem rastreado pelos times quanto o Cycle Time (que é bem representado nas colunas do Kanban), recomenda-se para tarefas cujo lead time não tenha sido satisfatório o desenho do processo de pré-jogo/refinamento (antes de entrar pra sprint) com as estimativas de tempo em cada etapa para entender onde está o gargalo.

É bem comum os times se focarem em otimizar o cycle time quando muitas vezes o gargalo é antes disso, em processos de análise, especificação, etc.

O desenho abaixo que mostra um processo de pedido de software até a sua entrega na nuvem mostra como muitas vezes o maior tempo é o de espera entre cada uma das etapas do desenvolvimento, em especial (mas não somente) como acontece no modelo waterfall.

Neste processo, enquanto que o desenvolvimento levou 3h, o teste 30min e o deploy 4h, o Lead Time da demanda custou um mês de espera pra empresa. O que você faria neste caso, pediria para os desenvolvedores programarem mais rápido ou você investiria tempo/dinheiro para automatizar o deploy?

Neste outro artigo, falo de métricas para Agile Coaches.

* OBS: curtiu o post? Dá uma olhada no meu curso sobre o mesmo assunto clicando no banner abaixo!