Engineering velocity

A maioria dos líderes de engenharia consegue dizer que o squad entregou 42 story points no último sprint. Poucos conseguem dizer se esse número está melhorando, caindo, ou o que está causando isso. Engineering velocity mede quanto trabalho valioso um time de software entrega em um período determinado. Sem uma visão clara disso, seus compromissos de entrega são pouco mais do que chutes qualificados. Esta página cobre a definição, como medir, o que é bom, como melhorar e como o DevStats traz os dados que você precisa para agir.

Principais conclusões

• Engineering velocity mede a taxa com que um squad entrega trabalho concluído em um período definido. Ela importa porque é a base de qualquer previsão de entrega confiável: sem ela, os compromissos de sprint são chutes, roadmaps são ficção e a confiança dos stakeholders se corrói toda vez que um release atrasa.
• A velocity é calculada como o total de story points (ou issues) concluídos por sprint. Um squad de alto desempenho com 6 a 8 engenheiros em ciclos de duas semanas costuma sustentar entre 60 e 90 story points, mas os benchmarks variam bastante por tamanho do time, convenções de sizing de tickets e duração do sprint. As tendências internas importam mais do que os números absolutos.
• O erro mais comum dos times é tratar velocity como uma pontuação de produtividade. Velocity mede o processo de entrega, não o valor individual dos players. Comparar velocity entre squads com convenções de sizing diferentes ou codebases distintas gera conclusões enganosas e corrói a segurança psicológica que faz os squads performarem bem.
• O DevStats rastreia engineering velocity automaticamente conectando ao seu provedor Git e ao seu issue tracker, com benchmarks em relação a mais de 1.000 times de engenharia. Comece um free trial e veja os números do seu squad em menos de dois minutos.

Definição de engineering velocity

Engineering velocity é a quantidade de trabalho que um time de desenvolvimento de software conclui em um período fixo, geralmente um sprint. Ela dá aos líderes de engenharia um sinal repetível de quanto um squad consegue entregar de forma confiável, o que a torna o insumo central para o planejamento de releases e a previsão de roadmap.

Tecnicamente, a velocity é calculada assim: Velocity = Total de story points (ou issues) concluídos / Número de sprints medidos. A maioria dos times acompanha uma média móvel de três a seis sprints para suavizar outliers. Quando os times usam contagem de issues em vez de story points, combinar velocity com dados de throughput dá uma visão mais completa da taxa de entrega. Times que entregam de forma consistente e com velocity previsível conquistam a confiança dos stakeholders, o que se traduz em melhor alinhamento de roadmap e menos pressão por scope creep.

Por que engineering velocity importa para times de engenharia

Quando squads não rastreiam velocity, os problemas de entrega ficam invisíveis até virarem emergências. Um time pode parecer ocupado em todos os sprints enquanto entrega consistentemente abaixo dos compromissos, sem nenhum sinal claro de onde o trabalho está travando. Sem dados de velocity, líderes de engenharia não conseguem distinguir um squad bloqueado por dependências externas de um que simplesmente assumiu mais do que consegue terminar. O resultado são sprints perdidos, erosão de confiança com stakeholders de produto e negócio, e um processo de planejamento que nunca melhora.

Velocity se conecta diretamente aos KPIs pelos quais líderes de engenharia são cobrados: entrega no prazo, cadência de release previsível e a capacidade de dar ao negócio uma resposta crível quando perguntam "quando isso vai sair?". Ela também alimenta a planning accuracy, que mede o quanto os compromissos de sprint se aproximam dos resultados reais. Times com alta planning accuracy tendem a ter uma velocity estável e bem compreendida. Dentro do SPACE framework, velocity fica na interseção de Activity e Efficiency, capturando output sem reduzi-lo a linhas de código ou horas trabalhadas.

Medir velocity é o passo diagnóstico. O que um líder de engenharia faz com esses dados, seja ajustando o escopo do sprint, removendo bloqueios ou reestruturando como o trabalho é dimensionado, é onde a melhoria real acontece.

Como medir engineering velocity

O cálculo padrão soma os story points concluídos em um sprint e calcula a média desse número ao longo de três a seis sprints para produzir uma baseline confiável. "Concluído" significa aceito pelo product owner e atendendo à definição de pronto do time, não apenas movido para uma coluna de done. As fontes de dados que você precisa são seu issue tracker (Jira, Linear, GitHub Issues) e seu provedor Git para confirmar o merge do PR. Para times que não usam story points, a contagem de issues por sprint é um proxy viável, especialmente quando combinada com o issue cycle time para considerar a complexidade dos tickets.

Não existe um benchmark universalmente publicado para velocity em story points da mesma forma que os DORA benchmarks existem para frequência de deployment, porque velocity depende muito de como um time dimensiona seus tickets. O que mais importa é a tendência do próprio squad ao longo do tempo. A tabela abaixo descreve níveis qualitativos de desempenho com base em padrões observados em times de engenharia, usando a estabilidade da tendência como sinal principal. Você pode comparar os padrões do seu squad com times similares usando os benchmarks do DevStats.

Nota: benchmarks variam por tamanho do time, maturidade da codebase e duração do sprint. Use esses níveis como sinais direcionais, não como metas absolutas.

Engineering velocity na prática: um exemplo real

Uma VP de Engenharia em uma empresa SaaS de 45 pessoas percebeu que a velocity do squad de plataforma havia caído de uma média móvel de 72 pontos por sprint para 48 ao longo de seis semanas. O squad não reportava nenhum bloqueio relevante nas standups. Quando ela puxou os dados de sprint e cruzou com o PR cycle time, descobriu que o tempo de retorno de revisão havia saltado de menos de 4 horas para mais de 2 dias. Dois players sênior estavam criando um gargalo nas revisões para o restante do squad, não por negligência, mas porque haviam assumido trabalho de arquitetura que não estava refletido no planejamento do sprint.

Ela fez duas mudanças: redistribuiu as atribuições de revisão para distribuir a carga entre três players e adicionou o trabalho de arquitetura como itens explícitos do sprint para que fosse contabilizado na capacidade durante o planejamento. Em três sprints, a velocity voltou para 68 pontos e a variância entre sprints caiu. Os dados mostraram onde olhar. A intervenção foi dela para desenhar e executar.

Como melhorar engineering velocity

1. Faça uma auditoria da disciplina de escopo do sprint. Puxe os últimos seis sprints e conte quantos tickets foram adicionados após o início do sprint. Trabalho não planejado é o maior inimigo da velocity. Estabeleça uma regra: nenhum ticket novo entra em um sprint sem remover escopo equivalente. Acompanhe isso usando seus dados de sprint para ver se a estabilidade de escopo se correlaciona com melhora de velocity.
2. Dimensione seus tickets corretamente. Se o squad frequentemente carrega tickets entre sprints, suas histórias são grandes demais. Quebre qualquer ticket estimado acima de 5 pontos em sub-tarefas. Tickets menores e bem definidos reduzem a chance de trabalho parcialmente concluído inflar sua contagem de in-progress enquanto derruba sua velocity.
3. Elimine gargalos de revisão. Code review lento é um indicador antecedente de queda de velocity. Se o PR cycle time está subindo, a velocity vai seguir. Estabeleça uma norma do time para o tempo de primeira resposta em revisão (menos de 4 horas é uma meta razoável para a maioria dos squads) e revise seus dados de code review semanalmente para detectar desvios cedo.
4. Torne a capacidade visível antes do planejamento do sprint. Previsões de velocity quebram quando a capacidade planejada não corresponde à disponibilidade real. Considere férias, rotações de plantão e compromissos entre times antes de fechar o escopo do sprint. O DevStats traz dados de allocation que mostram como o tempo de engenharia está distribuído entre tipos de trabalho, o que torna o planejamento de capacidade mais preciso.
5. Separe velocity de avaliação de desempenho. Squads que sabem que velocity é usada para julgar players individualmente vão manipulá-la. Mantenha velocity como uma métrica de processo, revise no nível do squad e use apenas para melhorar o planejamento, não para ranquear pessoas.

Engineering velocity vs. throughput

Engineering velocity e throughput são relacionados, mas medem coisas diferentes: velocity rastreia o valor ponderado do trabalho concluído (story points), enquanto throughput conta o número bruto de itens entregues independentemente do tamanho.

Use velocity quando seu squad trabalha em sprints com estimativa em story points. Use throughput quando o time opera em um modelo de fluxo contínuo ou quando você quer uma visão da taxa de entrega independente de sizing.