Velocity metric

A maioria dos líderes de engenharia descobre que a velocity do squad está quebrada quando uma sprint review desanda na frente dos stakeholders. Uma velocity metric é a medida de quanto trabalho um time conclui em um período determinado, geralmente expressa em story points ou número de issues entregues por sprint. Quando você acompanha isso de forma consistente, ela se torna um dos sinais mais claros para prever entregas, identificar gargalos sistêmicos e fazer compromissos críveis com o negócio. Esta página cobre a definição, como medir, benchmarks, como melhorar e como o DevStats exibe esses dados.

• A velocity metric mede a quantidade de trabalho que um squad conclui por sprint ou período. Ela importa porque, sem uma baseline confiável, todo compromisso de roadmap é um chute, e previsões erradas corroem a confiança entre engenharia e o restante do negócio.
• A velocity é calculada dividindo o total de story points concluídos pelo número de sprints medidos. Times de alta performance costumam manter a velocity consistente de sprint para sprint, com variação abaixo de 20%. O número de um único sprint não diz quase nada. O que conta é a tendência.
• O erro mais comum dos times é tratar a velocity como nota de desempenho em vez de ferramenta de planejamento. Comparar velocity entre squads ou pressionar players para inflá-la destrói o sinal. A velocity só tem valor quando reflete estimativas honestas e gestão de escopo consistente dentro de um único time ao longo do tempo.
• O DevStats rastreia a velocity automaticamente conectando ao seu issue tracker e provedor Git, com benchmarks contra mais de 1.000 times de engenharia. Comece um teste gratuito e veja os números do seu squad em menos de dois minutos.

Definição de velocity metric

A velocity metric é o total de trabalho que um time de software conclui em um período fixo, geralmente uma sprint. É expressa com mais frequência em story points, mas também pode ser medida por contagem de issues ou de features. A fórmula padrão é: Velocity = total de story points concluídos / número de sprints medidos.

Para fins de planejamento, os times costumam calcular a média da velocity das últimas três a cinco sprints para suavizar outliers. Essa média móvel se torna o insumo para a previsão de releases: divida o tamanho total estimado do backlog pela velocity média para obter uma data de entrega esperada. Quando a sua acurácia de planejamento é alta e a velocity é estável, os compromissos com stakeholders ficam muito mais fáceis de defender.

Por que a velocity metric importa para times de engenharia

Squads que não acompanham a velocity metric de forma consistente tendem a prometer demais e entregar de menos. Sem uma baseline, os gestores de engenharia não têm nenhum insumo objetivo para o planejamento de sprint, o que faz as decisões de capacidade dependerem de intuição. O resultado são prazos perdidos, scope creep e parceiros de produto frustrados que param de confiar nas estimativas de engenharia.

A velocity se conecta diretamente aos KPIs que importam para líderes de engenharia: taxa de entrega no prazo, previsibilidade do roadmap e alocação de recursos. Quando a velocity cai bruscamente, costuma ser um sinal antecipado de algo estrutural: trabalho demais em revisão, interrupções não planejadas ou um backlog cheio de tickets subestimados. Acompanhar os dados de sprint junto com a velocity dá o contexto necessário para distinguir uma sprint ruim pontual de um problema sistêmico. Dentro do SPACE framework, a velocity se mapeia principalmente às dimensões de Activity e Efficiency, refletindo a consistência com que um squad move o trabalho pelo pipeline de entrega.

Medir é o primeiro passo. O que você faz com os dados, seja reestruturar o planejamento de sprint, ajustar as práticas de estimativa ou remover bloqueadores, é decisão do gestor de engenharia.

Como medir a velocity metric

Para calcular a velocity, some os story points marcados como concluídos no fechamento de cada sprint e calcule a média dentro da janela escolhida (três a cinco sprints é o padrão). Seu issue tracker é a fonte de dados principal. Os dados de atividade Git do seu provedor funcionam como um bom cruzamento: se commits e pull requests estão altos mas issues concluídos estão baixos, algo está bloqueando a entrega, não o desenvolvimento. Você pode ver esses padrões lado a lado usando o recurso de throughput do DevStats, que mede itens de trabalho concluídos ao longo do tempo.

Não existe um benchmark publicado único para velocity da forma que os DORA metrics existem para frequência de deployment, porque a velocity é relativa ao sistema de estimativas do próprio time. O que importa é a consistência interna. A tabela abaixo descreve níveis qualitativos de desempenho com base na variação de sprint para sprint, que é o sinal mais relevante.

Os benchmarks variam bastante conforme o tamanho do time, a complexidade do código e o modelo de release. Use sua própria tendência histórica como referência principal e compare com os benchmarks de engenharia externos apenas como verificação de sanidade.

Velocity metric na prática: um exemplo real

Uma VP de Engenharia em uma empresa SaaS de 40 pessoas percebeu que a velocity do squad havia caído 30% ao longo de três sprints consecutivas, mas o time não reportava nenhum bloqueador nas standups. Ela cruzou os dados de cycle time de issues com as taxas de conclusão de sprint e descobriu que um grande volume de tickets estava sendo movido para "concluído" somente após o fechamento da sprint, inflando o carry-over da sprint seguinte. O processo de estimativa estava mascarando o problema real de throughput.

Ela fez uma única mudança: exigiu que qualquer ticket não concluído até o oitavo dia da sprint fosse explicitamente re-estimado e re-escopo antes da sprint review. Em duas sprints, a taxa de carry-over caiu de forma significativa e a baseline de velocity se estabilizou. Ela usou essa baseline estável para construir uma previsão de roadmap do Q3 crível para o time executivo, algo que ela não conseguia fazer com confiança há mais de seis meses.

Como melhorar a velocity metric

1. Audite o processo de estimativa primeiro. Se as estimativas de story points variam muito entre os players, o número de velocity é ruído. Faça uma sessão de calibração onde o squad estima os mesmos cinco tickets de referência em conjunto. Dimensionamento relativo consistente é mais importante do que qualquer escala absoluta de pontos.
2. Reduza os limites de work-in-progress. WIP alto é um dos supressores mais confiáveis de velocity. Quando os players alternam contexto entre quatro tickets ao mesmo tempo, nenhum deles fecha rapidamente. Defina um limite de WIP por player e aplique por duas sprints antes de avaliar o impacto.
3. Acompanhe o PR cycle time como indicador antecipado. Quando o PR cycle time sobe, os issues concluídos tendem a cair na sprint seguinte. Identificar gargalos de revisão cedo dá a chance de intervir antes que eles afetem a velocity.
4. Proteja o escopo da sprint após o segundo dia. Trabalho não planejado adicionado no meio da sprint é uma das principais causas de variação de velocity. Crie um processo formal de intake para solicitações urgentes, com decisões explícitas de trade-off em vez de adições silenciosas de escopo.
5. Revise os padrões de alocação. Se os players estão divididos entre vários squads ou projetos, a capacidade disponível é menor do que o headcount sugere. O recurso de allocation do DevStats mostra como o tempo de engenharia está de fato distribuído, dando os dados para uma conversa honesta sobre foco.

Velocity metric vs. throughput

Velocity e throughput são relacionados, mas medem coisas diferentes: velocity mede story points concluídos por sprint, enquanto throughput mede a contagem bruta de itens de trabalho concluídos por unidade de tempo, independentemente do tamanho ou estimativa.

Use velocity quando o seu squad trabalha em sprints de duração fixa com estimativas em story points. Use throughput quando operar em um modelo de fluxo contínuo ou quiser uma visão da taxa de entrega independente do tamanho dos itens.