Velocity: como usar a velocidade do time

O que é velocity (velocidade do time)

Velocity — ou velocidade do time — é a média de pontos que um time entrega por sprint. O cálculo é simples: ao final de cada sprint, você soma os story points dos itens que foram realmente concluídos (não os planejados, não os "quase prontos") e tira a média das últimas 3 a 5 sprints. Se o time fechou 22 pontos numa sprint, 26 na seguinte e 24 na terceira, a velocity dele gira em torno de 24 pontos.

Repare em duas palavras importantes dessa definição. Primeiro, média: velocity não é o recorde do time nem o número da última sprint isolada — é a tendência ao longo de algumas sprints, que amortece semanas boas e ruins. Segundo, concluídos: só entra na conta o que atingiu a definição de pronto do time. Uma user story 90% feita vale zero para a velocity daquela sprint; ela conta inteira na sprint em que for de fato finalizada. Essa regra parece dura, mas é ela que mantém o número honesto.

A velocity nasceu nos times de software, mas funciona para qualquer equipe que trabalhe em sprints com itens estimados em pontos: um time de marketing que entrega campanhas, um RH que roda projetos de onboarding e clima, um time de operações que padroniza processos. O que ela responde, em qualquer área, é a mesma pergunta: "quanto trabalho, em média, cabe numa sprint deste time?"

Para que a velocity serve

A velocity tem duas utilidades principais — e só duas.

1. Planejar a próxima sprint com realismo

Na sprint planning, a velocity é o freio de mão contra o otimismo. Sem ela, todo time tende a planejar pelo desejo: "dá pra fazer tudo isso, vai". Com ela, a conversa muda de opinião para dado.

Um exemplo concreto. A Renata lidera um time de marketing que roda sprints de duas semanas. Nas últimas quatro sprints, o time fechou 18, 21, 17 e 20 pontos — velocity de ~19. Na planning, o time quer puxar 28 pontos porque "o trimestre está apertado". A Renata não precisa discutir motivação nem esforço: basta mostrar o histórico. Ou o time puxa ~19 pontos e entrega, ou puxa 28 e devolve 9 no fim da sprint — junto com a frustração de "falhar" de novo. A velocity transforma o planejamento em um compromisso que o time consegue honrar.

Vale dizer: velocity e capacidade do time andam juntas, mas não são a mesma coisa. A velocity é o histórico (quanto o time costuma entregar); a capacidade é o ajuste fino da sprint específica (quem está de férias, quantos feriados caem no período, quanto tempo vai para suporte). O bom planejamento parte da velocity e desconta a capacidade real daquela quinzena.

2. Projetar prazos de entregas maiores

A segunda utilidade é responder à pergunta que todo gestor recebe: "isso fica pronto quando?". Se o backlog de um projeto soma 120 pontos e o time tem velocity de 20, a projeção honesta é algo em torno de 6 sprints — não porque alguém prometeu, mas porque é o que o histórico sustenta. É uma estimativa, não um contrato: conforme as sprints passam e o escopo se refina, a projeção se ajusta.

Esse uso é especialmente valioso para conversar com stakeholders. Em vez de prazos chutados na pressão da reunião, você apresenta uma faixa baseada em dados ("entre 5 e 7 sprints, dependendo do que descobrirmos no caminho") e atualiza a cada review. No TeamBOX, o termômetro da sprint faz esse acompanhamento no dia a dia — cruzando a meta de pontos com o tempo decorrido e o que já foi entregue — e o burndown mostra se a sprint atual está dentro do ritmo histórico.

Para que a velocity NÃO serve

Aqui mora o erro mais comum — e o mais caro. A velocity é uma régua interna e relativa: ela só faz sentido dentro do time que a produziu. Usá-la fora desse contexto quebra a ferramenta.

Não serve para comparar times

Trinta pontos do time de produto não equivalem a trinta pontos do time de engenharia, nem a trinta do time de RH. Cada time calibra sua régua de pontos do próprio jeito: o que é um item de 5 pontos para um, pode ser um 8 para outro — e os dois estão certos, porque pontos medem esforço relativo dentro daquele time, não uma unidade universal. Comparar velocities entre times é como comparar temperaturas medidas em escalas diferentes sem converter: o número maior não significa nada.

Não serve como meta de desempenho ou indicador de RH

Quando a velocity vira meta ("o time precisa subir de 20 para 30 pontos até o fim do trimestre"), acontece um fenômeno previsível: inflação de estimativas. O item que valia 3 pontos passa a valer 5, o de 5 vira 8, e em duas sprints a velocity "subiu" 40% sem que uma entrega a mais tenha saído. O número obedeceu à meta; a realidade, não. Pior: o time perdeu a régua honesta que usava para planejar, e agora ninguém sabe mais quanto cabe numa sprint.

Se você é gestor ou RH e quer medir a saúde da entrega, use a velocity apenas como instrumento do próprio time e olhe para outros sinais: tendência das métricas de sprint, qualidade do que chega ao usuário, previsibilidade (o time entrega o que planeja?) e o sentimento do time. Métrica que vira meta deixa de medir.

Não serve para avaliar pessoas

Derivação ainda mais perigosa: "o Fulano entregou 12 pontos e a Ciclana só 6". Pontos são estimados e entregues pelo time, não por indivíduos — uma user story de 8 pontos pode ter passado por três pessoas, e a pessoa que destravou o item mais difícil talvez não apareça em número nenhum. Avaliar gente por pontos pune quem ajuda os outros, quem pega os problemas cabeludos e quem faz o trabalho invisível que sustenta o time. Avaliação de desempenho tem lugar certo: a conversa individual, o PDI, o acompanhamento contínuo — não a planilha de pontos.

Quantas sprints até a velocity estabilizar

Uma velocity confiável precisa de 3 a 5 sprints com três condições mantidas:

• O mesmo time — entradas e saídas de pessoas mudam a régua. Um time que ganhou dois integrantes não fica automaticamente mais rápido nas primeiras sprints (às vezes fica mais lento, pelo custo de onboarding).
• A mesma duração de sprint — comparar sprints de 1 semana com sprints de 2 não faz sentido; padronize antes de medir.
• A mesma régua de estimativa — se o time recalibrou o que significa "1 ponto" no meio do caminho, o histórico anterior perde a validade.

Nas primeiras sprints de um time novo, trate os números como calibragem, não como referência. É normal a primeira sprint fechar com metade do planejado — o time ainda está aprendendo a estimar, a fatiar itens e a conhecer o próprio ritmo. Um time de RH que a Camila montou para tocar o projeto de revisão de cargos, por exemplo, fechou 8 pontos na primeira sprint, 14 na segunda e 15 na terceira: a velocity útil só começou a existir ali pela quarta sprint, na casa dos 14–15.

Sprints atípicas merecem uma anotação. Se metade do time estava de férias, se caiu um feriadão no meio, se houve uma virada de prioridade da empresa — registre e, se a distorção for grande, exclua aquela sprint da média (ou use uma média das últimas sprints "normais"). O objetivo é que o número represente o ritmo típico do time, não as exceções.

Velocity caiu: o que fazer (e o que não fazer)

Primeiro, respire: queda pontual não é problema. Velocity oscila por natureza — uma sprint com feriado, um item que se revelou maior do que parecia, uma emergência que roubou dois dias do time. Uma sprint abaixo da média seguida de retorno ao normal é ruído, não tendência.

O sinal que merece investigação é a queda sustentada: três ou mais sprints seguidas abaixo do histórico. Aí vale levar o tema para a retrospectiva — não como cobrança ("por que vocês estão entregando menos?"), mas como diagnóstico conjunto ("o que mudou no nosso trabalho?"). As causas mais comuns:

1. Itens mal refinados. Histórias grandes e vagas viram surpresa no meio da sprint. O remédio é investir no refinamento do backlog: fatiar itens, escrever critérios de aceite, tirar dúvidas antes da planning.
2. Interrupções e demandas paralelas. O time planeja 20 pontos, mas passa 30% do tempo apagando incêndio de fora da sprint. Isso é um problema de proteção do escopo, não de esforço — e é papel do gestor blindar o time ou reservar capacidade explícita para o imprevisto.
3. Dívida acumulada. Em qualquer área, atalhos cobram juros: o processo remendado do trimestre passado, o material feito às pressas, o código sem teste. Se cada entrega nova exige retrabalho sobre as anteriores, a velocity desce degrau por degrau. A saída é reservar espaço nas sprints para pagar essa dívida.
4. Mudança de composição do time. Saiu alguém experiente, entrou alguém novo — a régua mudou. Não é queda de desempenho; é recalibragem. Dê 2 ou 3 sprints antes de tirar conclusões.
5. Desmotivação ou sobrecarga. Às vezes o número está contando uma história sobre pessoas, não sobre processo. Queda de velocity combinada com clima pesado, 1:1s cancelados e sinais de cansaço pede uma conversa individual, não um plano de produtividade.

E o que não fazer: não pressione o time a "subir os pontos". A pressão sobre o número produz inflação de estimativa ou horas extras insustentáveis — nos dois casos, você perde a informação e desgasta as pessoas. Se a sprint descarrilou de vez, o caminho é outro: entender o que fazer quando a sprint falha e corrigir a causa, não o termômetro.

Como começar a usar velocity no seu time

Um checklist enxuto para colocar a velocity para trabalhar a seu favor:

• Padronize a duração da sprint (1 ou 2 semanas, e mantenha) antes de começar a medir.
• Estime em pontos, no nível certo: nos moldes do TeamBOX, os story points ficam na User Story — nem na Feature (grande demais), nem na Task (granular demais).
• Conte só o concluído: item pela metade vale zero na sprint; entra inteiro quando fechar.
• Espere 3 a 5 sprints antes de usar o número para planejar ou projetar prazos.
• Use a média, não o pico: planejar pela melhor sprint da história é receita de frustração.
• Anote as exceções: férias, feriados e viradas de prioridade explicam oscilações e evitam conclusões erradas.
• Combine com o time o que a velocity é (ferramenta de planejamento de vocês) e o que não é (meta, ranking, avaliação) — dizer isso em voz alta, logo no início, previne a maior parte do mau uso.
• Revisite na retrospectiva quando a tendência mudar: o número abre a conversa; quem explica é o time.

Tratada assim — como um espelho do ritmo real do time, e não como um chicote — a velocity vira uma das ferramentas mais baratas e úteis da gestão ágil: ela dá previsibilidade para quem planeja, protege o time do excesso de otimismo e transforma a pergunta "quando fica pronto?" numa resposta que dá para sustentar.