Postagens

Velocidade do sprint: como medir, prever e parar de usar mal

Ilustração de um painel de sprint com um mostrador de velocímetro e uma fila de barras a subir representando os story points concluídos por sprint, estilo editorial moderno e plano com tons vibrantes de roxo e azul, uma pequena equipa ágil a analisar o gráfico em conjunto

Kelly Lewandowski

Última atualização 07/06/20268 min de leitura

A velocidade é a métrica ágil mais fácil de calcular e a mais fácil de estragar. Some os story points que a sua equipa concluiu no último sprint. É só isso. O problema começa no momento em que alguém trata esse número como uma meta, uma nota de produtividade ou uma promessa de entrega exata. A velocidade tem exatamente duas funções legítimas: ajudá-lo a prever, de forma aproximada, quando um bloco de trabalho ficará pronto e dar à equipa uma noção realista de quanto puxar para o próximo sprint. Usada para qualquer outra coisa, faz mais mal do que bem. Veja como cumprir bem ambas as funções e como detetar o mau uso antes que se alastre.

O que a velocidade do sprint realmente é

A velocidade é o número de story points que a sua equipa concluiu num sprint. Concluído significa terminado segundo a sua Definition of Done, e não "em QA" ou "quase integrado". Trabalho a meio conta zero. Uma história arrastada de um sprint para outro pontua no sprint em que de facto termina, não naquele em que começou. É esta a definição completa. A velocidade não é uma medida de esforço, de horas ou de quão arduamente as pessoas trabalharam. É uma medida de produção na moeda de story points da própria equipa, e é precisamente por isso que só faz sentido dentro dessa equipa.

Os pontos são relativos à equipa

Os pontos de uma equipa estão calibrados para essa equipa. Um 8 de uma equipa é um 3 de outra. É este o único facto que invalida a maioria das comparações de velocidade, e voltaremos a ele.

Como calculá-la (e porque é que um único número engana)

A fórmula base é uma média dos seus sprints recentes: Velocidade média = total de pontos concluídos ÷ número de sprints Use pelo menos 3 sprints, idealmente 6 ou mais, e conte apenas sprints com uma equipa razoavelmente estável. Aqui está um conjunto realista de seis sprints:

22, 28, 19, 31, 24, 26

Pontos concluídos por sprint

Velocidade média

19–31

Intervalo real

A média é 25. Mas nenhum sprint entregou de facto 25, e a dispersão real vai de 19 a 31. Se planear todos os sprints em torno de "25", vai assumir demais nos sprints mais lentos e encher de menos nos mais rápidos. A média é um ponto de partida para a conversa, não um contrato. É por isso que a Calculadora de velocidade do sprint apresenta um intervalo e uma pontuação de consistência ao lado da média. Cole os seus últimos sprints e ela diz-lhe não só o ponto central, mas quão fiável esse ponto central é. Uma equipa com 24, 25, 26 está numa situação muito diferente de uma com 12, 38, 25, mesmo que ambas tenham média de 25.

Previsão: use intervalos, não números únicos

É aqui que a maioria dos conselhos sobre velocidade falha. A jogada clássica é "backlog ÷ velocidade média = sprints até terminar". Com um backlog de 200 pontos e uma velocidade média de 25, dá 8 sprints. Limpo, confiante e quase de certeza errado, porque finge que a sua velocidade não tem variância. A sua velocidade tem variância, por isso a sua previsão também deveria ter. A versão simples e honesta é o método das três previsões: prever com uma velocidade conservadora, uma provável e uma otimista.

Cenário	Velocidade usada	Backlog de 200 pontos
Conservador	Média dos seus 3 sprints mais lentos (~22)	~10 sprints
Provável	Média geral (25)	8 sprints
Otimista	Média dos seus 3 sprints mais rápidos (~28)	~7 sprints

Agora pode dizer a um stakeholder "7 a 10 sprints, muito provavelmente 8" em vez de um número único que mais tarde terá de desdizer. Como Mike Cohn e outros defendem há muito, uma afirmação do tipo "temos 90% de confiança de que isto cai entre o sprint 7 e o sprint 10" é simultaneamente mais útil e mais defensável do que falsa precisão.

Indique sempre um intervalo

Quando alguém lhe pede uma data, dê duas: a otimista e a conservadora. Um intervalo comunica a incerteza com honestidade e protege-o quando a realidade cai algures pelo meio, o que quase sempre acontece.

Para equipas que querem probabilidades reais, a simulação de Monte Carlo é o passo seguinte. Em vez de três cenários escolhidos à mão, corre milhares de futuros simulados ao amostrar aleatoriamente os seus sprints históricos e depois reporta os resultados em percentis: uma conclusão no percentil 50 (mediana), no 85 e no 95. "85% de probabilidade de terminarmos até ao sprint 9" é uma afirmação muito mais forte do que qualquer média consegue dar. Não precisa de uma estimativa pontual única; precisa de uma distribuição. Ilustração de um cone de incerteza a abrir-se a partir de um ponto de partida em direção a uma bandeira de chegada, com vários caminhos de probabilidade em faixas de azul e roxo em degradê, estilo vetorial moderno e plano, sem texto nem números

Ilustração de um cone de incerteza a abrir-se a partir de um ponto de partida em direção a uma bandeira de chegada, com vários caminhos de probabilidade em faixas de azul e roxo em degradê, estilo vetorial moderno e plano, sem texto nem números

Como as equipas usam mal a velocidade

A Scrum.org chegou ao ponto de publicar um artigo intitulado "Story Points are not the Problem, Velocity is." O dimensionamento dos pontos é, na sua maioria, inofensivo; o estrago vem do que os gestores fazem com o número de velocidade resultante. Estes são os quatro modos de falha a vigiar.

⚖️Comparar equipas

A Equipa A faz 40, a Equipa B faz 25, logo a Equipa A é "mais produtiva". Errado. Os pontos são relativos à equipa, por isso a comparação não mede nada. Só ensina a Equipa B a inflacionar.

📈Como métrica de produtividade

No momento em que a velocidade passa a ser um número pelo qual as pessoas são avaliadas, deixa de medir a produção e começa a medir quanta pressão a equipa sente. A lei de Goodhart em ação.

🎯Como compromisso

"Fizeste 30 no último sprint, logo compromete-te com 30." Isto transforma uma previsão numa quota e empurra a equipa a inflacionar estimativas até o número ser seguro de atingir.

🎲A partir de um único sprint

Um sprint é ruído. Um feriado, uma falha de serviço ou um bug cabeludo fazem-no oscilar descontroladamente. A velocidade só faz sentido como tendência ao longo de vários sprints.

O fio condutor: cada mau uso transforma a velocidade de uma ferramenta que a equipa usa numa meta pela qual a equipa é julgada. Assim que essa inversão acontece, o número passa a ser manipulado e perde-se o sinal honesto com que se começou.

A espiral mortal da inflação

Pressione uma equipa a aumentar a sua velocidade e ela aumenta, de imediato, ao dimensionar discretamente o mesmo trabalho com mais pontos. A velocidade sobe, nada é entregue mais depressa e agora os seus dados históricos ficam envenenados para previsões. A métrica que estava a otimizar destrói a única coisa para que servia.

Velocidade bem feita

Usada como auxiliar interno de planeamento e nada mais, a velocidade compensa. Uma lista de verificação curta para a manter honesta:

Conte apenas o trabalho totalmente concluído segundo a sua Definition of Done.

Faça a média de mais de 6 sprints e observe a tendência, não um número isolado.

Preveja com intervalos ou percentis, nunca com uma única data de "pronto até".

Refaça a base de referência após mudanças significativas na equipa; a velocidade antiga não se transfere.

Nunca mostre a velocidade num slide que compare equipas ou indivíduos.

Mantenha a conversa de estimativa; a discussão importa mais do que os pontos.

É este último ponto que as equipas esquecem. A velocidade é um subproduto de boas estimativas, não o objetivo delas. O valor do planning poker está na conversa que traz à tona a complexidade escondida antes que ela o apanhe a meio do sprint. O número que daí resulta é apenas contabilidade.

A velocidade não é a sua única opção

Se a velocidade não para de ser usada como arma na sua equipa, ou se as suas histórias variam demasiado de tamanho para que os pontos sejam estáveis, tem alternativas. Algumas equipas abandonam a estimativa por completo e fazem previsões diretamente a partir do throughput. Um passo mais leve é manter a velocidade mas apoiar-se em métricas de fluxo nas partes em que ela funciona mal. O throughput (itens terminados por sprint) e o cycle time (quanto tempo um item leva do início à conclusão) medem a entrega com marcas de tempo reais em vez de estimativas.

Pergunta	Melhor métrica
Quanto puxar para um sprint	Velocidade ou throughput
Quando é que este backlog termina	Monte Carlo sobre velocidade/throughput
Porque é que o trabalho demora tanto	Cycle time e trabalho em curso
Estamos a melhorar ao longo do tempo	Tendência do cycle time

A maioria das equipas maduras acaba por usar ambos: velocidade para a conversa ao nível do sprint, métricas de fluxo para a previsão de entrega e a deteção de estrangulamentos. Respondem a perguntas diferentes, e nenhuma delas é um placar de produtividade.

Conclusão

A velocidade é uma lanterna, não um velocímetro. Ajuda a equipa a ver, de forma aproximada, quanto consegue assumir e mais ou menos quando um conjunto de trabalho vai terminar. Aponte-a às pessoas em vez do trabalho e ela deixa de dizer a verdade. Acompanhe-a ao longo de vários sprints, faça previsões em intervalos e mantenha-a dentro da equipa. Quando precisar dos números calculados depressa, a Calculadora de velocidade do sprint transforma os seus últimos sprints numa média, num intervalo realista, numa pontuação de consistência e numa previsão do backlog em poucos segundos. Para o lado da estimativa que a alimenta, o planning poker mantém o foco onde ele deve estar: na conversa, não no placar.

Pelo menos 3 para obter uma média aproximada, mas 6 ou mais antes de confiar nela para previsões. Menos do que isso e um único sprint atípico distorce tudo. A equipa também deve estar razoavelmente estável ao longo desses sprints.

Apenas se esses itens tiverem sido estimados em pontos e concluídos dentro do sprint. Muitas equipas deixam bugs e trabalho de suporte sem pontos e acompanham-nos em separado, o que mantém a velocidade focada na entrega de funcionalidades planeadas. Escolha uma abordagem e seja consistente para que o seu histórico se mantenha comparável.

Os story points são calibrados por equipa, por isso o 5 de uma equipa é o 13 de outra. Comparar os números em bruto não mede nada de real e pressiona as equipas a inflacionar as suas estimativas. Se precisa de uma visão entre equipas, olhe para os resultados entregues ou para o cycle time, não para os pontos.

Não. A velocidade mede a produção numa unidade específica da equipa, não o valor entregue nem o esforço despendido. Uma equipa pode aumentar a sua velocidade sem entregar nada de mais útil, simplesmente dimensionando o trabalho com mais pontos. Trate-a como um dado de planeamento, nunca como uma métrica de desempenho.