O que é Velocity?
Em português: Velocidade
Velocity registra trabalho estimado concluído por Sprint em uma escala local e pode apoiar previsão interna.
Velocity é uma medida usada por algumas equipes para registrar quanto trabalho estimado foi concluído em cada Sprint, frequentemente somando story points de itens Done. Pode apoiar planejamento e previsão dentro do mesmo time. Não é exigência do Scrum, não compara produtividade entre equipes e não mede valor entregue. Sua interpretação exige olhar variação, qualidade e contexto.
Origem
Velocity se difundiu em práticas de planejamento ágil como medida local de capacidade relativa. O Scrum Guide de 2020 não exige seu cálculo nem o uso de story points. Scrum.org alerta para a confusão entre velocity e produtividade, pois a pontuação pode mudar sem melhora real de entrega ou valor.
Fonte primária: Myth: Velocity is Productivity
Na prática
Velocity costuma ser a soma de pontos de história associados a itens concluídos por uma equipe em uma Sprint. Algumas equipes usam contagem de itens ou outra unidade, mas devem declarar a unidade para evitar comparação enganosa. É um registro histórico de trabalho estimado que chegou ao critério de conclusão do time. O Scrum Guide não exige velocity nem story points. A métrica pode apoiar previsões internas; não mede diretamente valor para clientes ou produtividade individual.
O que acontece quando falta
Um time pode planejar bem sem story points ou velocity, usando dados de fluxo, contagem de itens e julgamento sobre capacidade. O problema não é a ausência do indicador, mas prever sem evidência e sem explicitar incerteza. Se velocity é usada, sua finalidade deve ser melhorar conversas internas sobre trabalho possível, não criar placar de desempenho.
Como calcular e interpretar velocity
Velocity costuma ser a soma de pontos de história associados a itens concluídos por uma equipe em uma Sprint. Algumas equipes usam contagem de itens ou outra unidade, mas devem declarar a unidade para evitar comparação enganosa. É um registro histórico de trabalho estimado que chegou ao critério de conclusão do time. O Scrum Guide não exige velocity nem story points. A métrica pode apoiar previsões internas; não mede diretamente valor para clientes ou produtividade individual.
Defina o que conta. Combine que apenas itens concluídos segundo a Definition of Done entram na soma. Trabalho parcialmente feito não vira fração arbitrária de pontos a cada Sprint, salvo política explícita que faça sentido para outra pergunta. Se um item de oito pontos só termina na Sprint seguinte, conte quando estiver pronto. Essa regra pode gerar variação entre ciclos, mas mantém a série ligada a conclusões reais.
Observe vários ciclos. Uma Sprint atípica não define capacidade futura. Férias, incidentes, dependências, tamanho dos itens e mudanças de equipe explicam parte da variação. Calcule uma faixa ou examine distribuição, não apenas a última observação. Uma média de 25 pontos pode conviver com Sprints de 14 e 33; prometer 25 exatos no próximo ciclo esconde incerteza. Registre contexto para interpretar mudanças.
Use na Sprint Planning com julgamento. Os Developers selecionam trabalho considerando capacidade, desempenho anterior e Definition of Done, segundo o Scrum Guide. Velocity pode ser uma informação, mas não decide sozinha. Um conjunto de itens com risco técnico novo pode ser menos previsível que trabalhos anteriores de mesma pontuação. O Sprint Goal orienta a escolha; preencher a capacidade nominal com pontos até uma meta numérica não cria objetivo coerente.
Projete com cuidado. Para estimar quando um conjunto de itens pode estar pronto, compare tamanho remanescente com série histórica de velocity, incluindo faixas e mudanças esperadas. Backlogs evoluem: itens entram, saem e são divididos. Somar pontos de trabalho distante e dividir por média fixa produz data com falsa precisão. Atualize projeção após cada Sprint e deixe claro o que é hipótese de escopo e capacidade.
Não compare equipes. Cada grupo calibra story points por referências próprias. Oito pontos de uma equipe podem representar trabalho muito diferente de oito em outra. A Definition of Done, especialidades, produto e dependências também variam. Um ranking por velocity pode incentivar inflação de estimativas e redução de qualidade para melhorar número. Compare resultados e restrições em contexto, sem fingir unidade universal de pontos.
Evite meta de crescimento. Se a gestão determina “a velocity precisa subir 20%”, o caminho mais fácil pode ser aumentar pontuação dos itens. O produto não melhora por isso. Uma queda também não prova pior desempenho: o time pode ter enfrentado problema complexo, investido em qualidade ou mudado a forma de fatiar. Investigue comportamento de entrega e resultado, em vez de recompensar a série mais alta.
Relacione a fluxo. Throughput conta itens concluídos por período; tempo de ciclo e lead time mostram duração; WIP mostra trabalho em andamento. Essas medidas ajudam a interpretar se a equipe entrega de forma mais previsível ou apenas altera pontos. Quando itens são pequenos e relativamente semelhantes, throughput pode apoiar previsão sem esforço de estimar cada um. A escolha é pragmática: qual métrica melhora decisão com menor custo e menor incentivo à distorção?
Considere valor e qualidade. Pontos concluídos representam trabalho estimado, não efeito no negócio. Uma Sprint pode ter velocity alta e pouca melhora para usuários. A Sprint Review e medidas de resultado ajudam a avaliar se o incremento valeu a pena. Defeitos e retrabalho podem transformar velocidade aparente em lentidão futura. Mantenha padrões de qualidade explícitos e evite usar velocidade como substituto de Product Goal.
Proteja a confiança. Métricas úteis dependem de dados honestos. Se toda variação gera punição, pessoas passam a inflar estimativas ou fragmentar cartões artificialmente. Converse sobre previsão como intervalo e aprendizado. O time pode decidir abandonar pontos quando eles deixam de trazer informação. O objetivo não é preservar o dashboard; é compreender capacidade e tomar decisões melhores sob incerteza.
Exemplo de série com variação
Exemplo hipotético: um time concluiu 18, 24, 20, 12 e 22 pontos nas últimas cinco Sprints, todos relativos à sua escala local. A quarta teve incidente operacional significativo. Na Planning seguinte, os Developers consideram o objetivo, férias e riscos de integração. Não tratam a média como cota obrigatória nem descartam automaticamente o ciclo de incidente. Os números são ilustrativos.
Um gestor compara a série com outra equipe que conclui 40 pontos. A comparação não mostra qual entrega mais valor: as escalas e trabalhos são diferentes. Para decidir uma data de lançamento, o Product Owner olha escopo atual, possível mudança de itens e uma faixa de capacidade. Também observa quantos itens terminam e quanto tempo ficam em andamento.
Se a equipe começa a estimar itens idênticos com o dobro de pontos, a velocity sobe sem que clientes recebam mais. O exemplo evidencia por que a métrica deve ser usada para previsão interna e inspecionada junto de fluxo e resultado.
Como usar velocity com segurança
Defina unidade
Declare escala e critério de conclusão.
Registre
Some apenas itens concluídos em cada Sprint.
Observe variação
Veja vários ciclos e seus contextos.
Projete
Use faixas com escopo e capacidade explícitos.
Compare
Olhe fluxo, qualidade e resultado do produto.
Revise
Mude a prática se incentivar distorção ou não ajudar.
Velocity e throughput
Velocity geralmente soma pontos estimados concluídos por Sprint; throughput conta itens concluídos por período. Pontos dependem de escala interna; contagem de itens depende de tamanho e tipo comparáveis. Ambos podem informar capacidade, mas nenhum mede valor sozinho. Um time pode usar um, os dois ou outra abordagem conforme as perguntas de planejamento.
Erros comuns
- Comparar equipes. Escalas de pontos não são universais.
- Impor aumento contínuo. Estimativas podem inflar.
- Contar trabalho parcial como pronto. A série perde ligação com entrega.
- Prometer pela média. Variação e escopo incerto desaparecem.
- Confundir pontos com valor. Resultado de produto precisa ser observado.
Para se aprofundar
Fontes primárias
- Myth: Velocity is Productivity, Scrum.org (2020)
- The Scrum Guide, Ken Schwaber e Jeff Sutherland (2020)
Termos relacionados
Comparativos relacionados
Aprenda mais sobre os assuntos relacionados.
Perguntas frequentes
O que é velocity em uma equipe ágil?
É a quantidade de trabalho estimado que uma equipe conclui por Sprint em sua própria escala, muitas vezes soma de story points de itens Done. A série histórica pode apoiar planejamento. Não representa valor para clientes nem produtividade individual. Para interpretar, observe variação, mudanças de escopo, composição e critérios de qualidade.
Velocity é obrigatória no Scrum?
Não. O Scrum Guide não exige velocity nem pontos de história. Os Developers consideram capacidade, desempenho anterior e qualidade ao selecionar trabalho, podendo usar diferentes formas de evidência. Throughput e tempo de ciclo são alternativas ou complementos. Escolha o método que ajuda a decidir sem criar custo ou incentivo à distorção.
Posso comparar velocity entre times?
Em geral, não. Cada time define referências de pontos, lida com trabalho diferente e pode ter Definition of Done distinta. Uma pontuação maior não demonstra mais valor nem maior eficiência. Comparações podem incentivar inflar estimativas ou reduzir qualidade. Para decisões organizacionais, examine resultados, fluxo, restrições e experiência dos clientes em contexto.
Como calcular velocity quando um item não termina?
Se a equipe soma pontos de itens Done, conte o item apenas na Sprint em que realmente atende à Definition of Done. Não distribua automaticamente frações de pontos por etapas concluídas. A variação resultante é informação sobre o fluxo. Se itens atravessam muitas Sprints, investigue tamanho, dependências e bloqueios, em vez de apenas ajustar contabilidade.
Velocity pode prever uma data?
Pode apoiar uma projeção com histórico e escopo conhecido, mas não fornecer data certa. Itens futuros podem mudar, e a capacidade varia. Use intervalos ou cenários e atualize a previsão a cada Sprint. Combine com fluxo e avaliação de riscos. Dividir soma de pontos distantes por uma média fixa costuma esconder incerteza importante.
