A maioria dos times de engenharia acompanha a sprint velocity como um número no burndown chart e nunca pergunta o que está por trás dela. A sprint velocity mede quanto trabalho um squad conclui em um sprint, expresso em story points, contagem de issues ou outra unidade combinada. Quando a velocity está inconsistente ou caindo, isso sinaliza um problema de processo que vale investigar: scope creep, critérios de aceitação confusos, trabalho não planejado ou players bloqueados. Esta página cobre a definição, como medir e fazer benchmark da sprint velocity, um exemplo real e como obter esses dados sem planilhas manuais.
TL;DR: Sprint velocity = total de story points (ou unidades) concluídos em um sprint. Use para prever capacidade e identificar problemas no processo de entrega, não para ranquear seus players.
Principais conclusões
- Sprint velocity é o total de trabalho que um squad conclui em um único sprint, medido em story points ou unidades equivalentes. Ela dá aos líderes de engenharia um sinal repetível para previsão e para identificar quando os processos de entrega estão quebrando antes que um prazo escorregue.
- A sprint velocity é calculada somando os story points de todas as issues concluídas ao final de cada sprint. Um squad saudável geralmente se estabiliza dentro de uma faixa de variação de 10 a 15% após três a cinco sprints. Variações bruscas de sprint para sprint são o sinal que merece investigação, não a média em si.
- O erro mais comum dos times com sprint velocity é tratá-la como uma pontuação de desempenho. Comparar velocity entre squads ou usá-la para ranquear players ignora diferenças na calibração de story points, tamanho do squad e tipo de trabalho. Velocity é uma ferramenta de planejamento, não uma nota de produtividade.
- O DevStats exibe dados de sprint velocity automaticamente ao se conectar ao seu issue tracker, com visões de tendência entre sprints e benchmarks comparando mais de 1.000 times de engenharia. Comece um trial gratuito e veja os números do seu squad em menos de dois minutos.
Definição de sprint velocity
Sprint velocity é o número total de story points (ou unidades de trabalho equivalentes) que um squad conclui em um único sprint. Ela é calculada ao final de cada sprint somando os pontos de todas as issues movidas para "concluído" antes do sprint fechar.
A fórmula é simples: Sprint velocity = soma dos story points concluídos em um sprint. Com o tempo, calcular a média de três a cinco sprints gera uma velocity contínua muito mais útil para o planejamento de capacidade do que qualquer resultado isolado. Times que conectam as tendências de velocity aos dados de precisão de planejamento têm uma visão mais clara de se as estimativas estão melhorando ou sistematicamente erradas.
Uma sprint velocity estável apoia diretamente os compromissos com stakeholders. Quando a velocity do seu squad é previsível, os product managers fazem promessas de roadmap confiáveis e os líderes de engenharia alocam capacidade com segurança.
Por que a sprint velocity importa para times de engenharia
Squads que não acompanham a sprint velocity de forma consistente acabam em um ciclo de planejamento reativo. Sem uma linha de base histórica confiável, o planejamento do sprint vira chute, e os compromissos não cumpridos se acumulam até que um prazo importante escorregue. Scope creep invisível e interrupções não planejadas corroem a capacidade sem que ninguém perceba até que o estrago esteja feito.
A sprint velocity se conecta diretamente aos KPIs centrais do líder de engenharia: entrega no prazo, execução previsível do roadmap e ritmo sustentável do time. Quando a velocity cai de forma inesperada, geralmente é o primeiro sinal de um problema mais profundo, como um volume crescente de trabalho não planejado, um gargalo no code review ou um squad com overhead excessivo de troca de contexto. Acompanhar as tendências de velocity junto com o throughput dá tanto o sinal de planejamento quanto o sinal de entrega em uma única visão.
Dentro do SPACE framework, a sprint velocity fica na interseção entre Eficiência e Atividade. Ela mede o output do processo, não o esforço individual. A métrica dá o ponto de partida. O engineering manager decide o que fazer com ela.
Como medir a sprint velocity
Para calcular a sprint velocity, extraia do seu issue tracker (Jira, Linear, GitHub Issues ou equivalente) a soma dos story points de todas as issues marcadas como concluídas até o fechamento do sprint. Exclua issues que foram puxadas no meio do sprint sem serem finalizadas, pois contar trabalho parcial infla o número e prejudica a confiabilidade do planejamento.
A fonte primária de dados é o seu issue tracker. Nenhum dado de Git é necessário para a velocity em si, mas combiná-la com o issue cycle time ajuda a explicar por que a velocity está alta ou baixa em um determinado sprint. Use uma média contínua de três sprints como linha de base de planejamento. O recurso de benchmarks do DevStats permite comparar as tendências de velocity do seu squad com times similares por tamanho e setor.
Não existe um benchmark universalmente publicado para sprint velocity da forma como o DORA publica benchmarks de frequência de deployment, porque as escalas de story points variam muito entre times. A tabela abaixo descreve níveis de desempenho qualitativos com base em consistência interna e precisão de planejamento, que são os sinais que mais importam.
| Nível de desempenho | Benchmark de sprint velocity | O que sinaliza |
|---|---|---|
| Elite | Variação dentro de 10% em 5+ sprints | Estimativa estável, entrega previsível, trabalho não planejado mínimo |
| Alto | Variação entre 15 e 20% em 5+ sprints | Geralmente previsível com interrupções ocasionais; planejamento é confiável |
| Médio | Variação de 20 a 35% de sprint para sprint | Inconsistência nas estimativas ou interrupções não planejadas recorrentes que merecem investigação |
| Baixo | Variação acima de 35% ou queda consistente em 3+ sprints | Quebra sistêmica no planejamento, trabalho não planejado significativo ou problemas de capacidade do squad |
Observação: os benchmarks variam por tamanho do squad, duração do sprint e calibração de story points. Use essas faixas como sinais direcionais, não como metas absolutas.
Sprint velocity na prática: um exemplo real
Uma VP de Engenharia em uma empresa SaaS de 40 pessoas percebeu que a velocity do squad de plataforma havia caído 30% em seis sprints consecutivos. O número bruto parecia um problema de desempenho. Quando ela cruzou os dados do sprint com a proporção de trabalho não planejado do squad, descobriu que cerca de 35% de cada sprint estava sendo consumido por escalações de suporte que nunca eram consideradas no planejamento. A queda de velocity era um sinal de capacidade, não um problema de output.
Ela reestruturou o processo de planejamento do sprint para reservar um buffer fixo para trabalho de suporte e criou uma rotação semanal de triagem para conter as interrupções. Três sprints depois, a velocity planejada se estabilizou e a precisão de planejamento do squad melhorou significativamente. Os dados revelaram o padrão. Ela tomou a decisão de como endereçá-lo.
Como melhorar a sprint velocity
1. Audite a proporção de trabalho não planejado a cada sprint. Antes de ajustar estimativas de story points ou o escopo do sprint, meça qual porcentagem de cada sprint é consumida por trabalho que não estava no plano original. Se o trabalho não planejado supera 20% de forma consistente, o problema de planejamento é externo ao processo de estimativa. Trate a fonte das interrupções primeiro.
2. Faça uma sessão de calibração de story points todo trimestre. O desvio nas estimativas é uma das causas mais comuns de variações de velocity. Reúna o squad para referenciar a escala de pontos com base em duas ou três histórias âncora. Calibração consistente transforma a velocity em um input confiável de planejamento, não em um sinal ruidoso.
3. Reduza as issues de carry-over. Issues que transbordam entre sprints inflam a velocity aparente do próximo sprint e distorcem a média contínua. Revise a taxa de carry-over sprint a sprint. Se mais de duas issues transbordam de forma consistente, o squad está se comprometendo além da capacidade. Ajuste o escopo antes do sprint começar, não depois que ele termina.
4. Combine velocity com PR cycle time. Um squad pode concluir todas as issues planejadas no papel enquanto PRs ficam em review por dias, atrasando a entrega real. Monitorar o PR cycle time junto com a velocity mostra se o trabalho concluído está de fato sendo entregue. O DevStats exibe os dois sinais em uma única visão para que você veja onde a cadeia de entrega está desacelerando.
5. Revise a alocação do squad antes de cada sprint. A capacidade planejada muda quando players tiram folga, entram de on-call ou são puxados para trabalho entre squads. Verificar os dados de alocação antes do planejamento do sprint evita que o squad se comprometa com metas de velocity que não refletem a capacidade real disponível.
Sprint velocity vs. throughput
Sprint velocity e throughput são relacionados, mas medem coisas diferentes. Velocity conta story points concluídos por sprint; throughput conta o número de issues ou pull requests concluídos por unidade de tempo, independentemente do tamanho.
| Sprint velocity | Throughput | |
|---|---|---|
| Mede | Story points concluídos por sprint | Quantidade de itens de trabalho concluídos por período de tempo |
| Começa quando | O sprint inicia | O item de trabalho entra em estado ativo |
| Termina quando | O sprint fecha | O item de trabalho chega a concluído |
| Melhor para | Planejamento de capacidade e previsão do sprint | Eficiência de fluxo e medição de entrega contínua |
Use velocity para planejamento e previsão baseados em sprint. Use throughput quando quiser medir o fluxo de entrega independente das unidades de estimativa, especialmente útil para squads que caminham para modelos de entrega contínua.