Como calcular a velocidade 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.

No artigo de hoje, vamos falar da métrica mais popular, a Velocidade!

Você vai ver neste artigo:

1. Velocidade (Velocity)
2. Velocidade no Azure Boards
3. Velocidade no Jira Software
4. Velocidade Manual
5. E quando a velocidade vai mal?

Vamos lá!

Velocidade (Velocity)

Essa é a métrica mais básica que todo Scrum Master ou Agile Coach tem de saber mensurar. Em algum momento alguém vai lhe questionar: qual a velocidade do seu time?

Não existe uma única unidade de medida, sendo as mais populares:

• Horas: muito comum, apesar de comumente falha, herdada do waterfall;
• Pontos: me refiro a Story Points (oriunda das User Stories) e não aos Pontos de Função e Pontos de Caso de Uso, também do waterfall. É muito utilizada como Scrum e XP. Falo mais dela no artigo de estimativas.
• Tamanho de Camiseta: ordem de grandeza em P, M, G, etc  para cada item, como os tamanhos de uma camiseta (t-shirt size no original). Possui racional parecido com a de Pontos e se desprende ainda mais do conceito de “horas/homem”;
• Contagem de Itens: ou issue count, você não estima, apenas conta o número de itens mesmo, muito utilizada em Kanban e de boa utilidade em times mais maduros;

Velocity funciona desde que você seja honesto, escolha uma unidade que funcione para o seu time e que você acompanhe a mesma, sem ficar mudando. O objetivo é você conhecer o ritmo do seu time para que seja possível identificar e fazer ajustes quando há variação pra menos ou para seguir melhorando os resultados no dia a dia.

Além disso, ter uma boa métrica de velocidade auxilia na previsibilidade do roadmap do Product Owner, obviamente sempre respeitando o bom senso e a máxima de que “a única constante em software é a mudança”.

Mas como medir a velocidade do time?

Os métodos ágeis são empíricos, logo, baseiam-se em experiência prática passada para poder tirar conclusões sobre o futuro próximo. Sendo assim, o único jeito de saber a velocidade do time é fazendo com que ele rode de uma a três sprints, no mínimo, com a mesma formação, para ter uma média e poder descobrir essa métrica.

Independente da unidade escolhida, você terá de registrar o montante planejado (estimado) e compará-lo ao fim do período com o montante efetivamente realizado (DONE). Lembrando que na agilidade não existe “quase pronto” ou “parcialmente entregue”. É fez ou não fez.

Muito importante ressaltar também que a velocidade de um time é reflexo de todo um contexto que envolve: tecnologia, perfis de pessoas, experiência do time, quanto tempo trabalham juntos, o quanto conhecem do projeto, etc. Qualquer alteração nesse sensível contexto irá provocar oscilações na velocidade. Quando estas oscilações são pequenas, não há problema, mas oscilações drásticas indicam riscos ao projeto e devem ser resolvidas.

Mais importante ainda é ressaltar que jamais você deve comparar a velocidade de dois times. Medimos a velocidade de um time para compará-lo sempre com ele mesmo, jamais com os outros.

Abaixo, vou explicar como medir a velocidade nas duas ferramentas de gestão ágil de projetos mais populares em corporações e na sequência dou mais algumas dicas para fazer à mão ou em ferramentas mais limitadas que não possuam relatórios de velocidade.

Velocidade no Azure Boards/DevOps

Na ferramenta Azure Devops a velocidade (Velocity) é calculada automaticamente no Product Backlog, desde que você use o campo Effort dos Product Backlog Items/User Stories (dependendo do seu template) corretamente. Você encontra esta informação no canto superior direito da tela, na visão de Product Backlog.

Também é possível adicionar um widget Velocity no dashboard do time, como abaixo.

• Barra azul claro representa o montante planejado;
• Barra verde escura, o montante finalizado na sprint (DONE);
• Barra verde clara, o montante finalizado depois da sprint terminar;
• Barra azul escuro, o montante que não foi finalizado;

O gráfico mostra essas barras sprint a sprint (últimas 5 sprints), além de ter um resumo da velocidade média no canto superior direito.

Velocidade no Jira Software

Na ferramenta Jira Software, a velocidade é calculada automaticamente no relatório Gráfico de Velocidade, desde que você utilize o campo de estimativa apropriado.

Qual é o campo de estimativa correto?

Se nas configurações do board principal do projeto a métrica de estimativa é Story Points, use o campo Story Points para estimar e com isso a velocidade será calculada por ele.

Agora se a configuração do board está como Estimativa de Tempo Original (horas), use este campo durante o preenchimento das issues para que o relatório saia correto.

E por último, se a configuração está como Contagem de Itens (Issue Count), então não há a necessidade do lançamento de qualquer estimativa, pois as Stories serão contadas apenas.

• Barra cinza significa o montante planejado;
• Barra verde significa o montante finalizado na sprint (DONE);

As barras são calculadas sprint a sprint e dependem que você esteja iniciando e encerrando as sprints corretamente na ferramenta, caso contrário a informação estará errada.

Além disso, logo abaixo do gráfico, na mesma página do relatório, você encontra as mesmas informações, em formato textual.

Se quiser dominar esta ferramenta, dá uma olhada no curso abaixo.

Velocidade “manual”

Caso você esteja utilizando alguma ferramenta que não lhe forneça os cálculos automáticos, como o Trello, você pode pode registrar e calcular de maneira manual, não é um processo complicado, apenas mais trabalhoso.

Minha sugestão é que você comece utilizando um Burndown Chart (clique no link se não conhecer). Uma vez que você tenha ele (no artigo do link eu forneço uma planilha para calcular no Excel) alimentado corretamente, basta que ao final de cada sprint você tome nota em uma planilha do planejado x realizado (canto superior esquerdo e canto inferior direito do burndown, respectivamente).

Após você ter registrado o planejado x realizado de umas 3 sprints, basta calcular a média ou mediana e você terá a tão sonhada métrica de velocidade do seu time para lhe ajudar com o projeto.

E quando a Velocidade vai mal?

A métrica de velocidade, 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 velocidade 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 a velocidade é 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.

Não gosta de estimativas mas ainda quer ter preisibilidade? Conheça a métrica Lead Time!

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!