Velocidade: para que serve e como calculá-la

A velocidade é a média de pontos de história que uma equipe conclui por sprint. Para que serve, por que ela deixa de funcionar no momento em que se torna uma meta e como mantê-la realista.

A velocidade é um indicador utilizado para previsões, não um KPI. No momento em que você avalia as equipes com base nela, ela é superestimada.

A velocidade é a média do número de pontos de história que uma equipe conclui por sprint nos últimos sprints. Essa é a definição completa. Ela existe com um único objetivo: projetar quantos sprints serão necessários para entregar o backlog, considerando a taxa real de entrega da equipe. Some os pontos restantes, divida pela velocidade e você terá uma previsão. Essa é, na verdade, a única função que ela cumpre.

Qualquer outro uso distorce o conceito. “Por que a velocidade foi menor neste sprint?” transforma cada retrospectiva em uma defesa do número. “A Equipe A tem uma velocidade maior do que a Equipe B” trata as calibrações independentes das duas equipes como comparáveis, quando na verdade não são. “Precisamos aumentar a velocidade em 20% neste trimestre” diz à equipe para fazer o número subir, e a equipe o fará — estimando o mesmo trabalho como maior, não realizando mais trabalho. A lei de Goodhart, em ação em um ciclo de duas semanas.

Como calcular isso

Pegue os pontos concluídos em cada um dos últimos três a cinco sprints. Calcule a média. Essa é a sua velocidade. Não faça ajustes para sprints “excepcionais” — os sprints excepcionais fazem parte do sinal que você está tentando suavizar. Não conte duas vezes o trabalho acumulado. Não conte, de forma alguma, as histórias parcialmente concluídas; elas são contabilizadas no sprint em que realmente forem concluídas. Quanto mais simples for o cálculo, mais difícil será manipular os resultados.

A velocidade se estabiliza depois que uma equipe vem trabalhando em conjunto por três ou quatro sprints. Uma nova equipe, uma nova história de referência, uma grande mudança no quadro de pessoal — todos motivos para descartar o número anterior e recomeçar do zero. O número não é uma característica da técnica; é uma característica desta equipe neste período. Uma equipe que perdeu dois membros ontem tem a velocidade de ontem, que, no entanto, corresponde a uma equipe diferente.

Quantos pontos de história por sprint?

Pesquisar “quantos story points por sprint” é um erro de categoria. Não existe um número padrão do setor, nem um número “ideal”, nem uma taxa por desenvolvedor por dia. A velocidade é a produtividade medida da equipe, e a única versão útil é a média móvel dos últimos sprints da própria equipe. Quinze pontos, quarenta pontos, cem pontos — nenhum deles é certo ou errado. Eles são calibrados com base na história de referência da equipe.

Velocity over six sprints with two outliers pulling the average above the sustainable rate 0 30 60 points avg 35 actual 29 s1 s2 s3 s4 s5 s6 easy sprint carry-over plan to the teal line, not the orange one
Os dois sprints mais fáceis elevam a média acima da taxa sustentável da equipe. Planeje com base no sprint típico, não na média.

Portanto, use a velocidade para fazer três coisas, e apenas três: estimar uma data para um escopo conhecido (escopo ÷ velocidade = número de sprints); decidir o que cabe no próximo sprint (escolher histórias até que somem cerca de 80–90% da média recente, deixando espaço para o não planejado); e identificar quando algo mudou (uma queda de 30% é um sinal que merece uma conversa na retrospectiva). O que você não pode fazer com ela: compará-la com os números de outra equipe, usá-la para avaliar a equipe ou convertê-la em “horas esperadas por desenvolvedor por dia”. Cada uma dessas ações é o mesmo erro com uma roupagem diferente.

O que dá errado

O principal erro mais comum: um gerente interpreta o valor da velocidade como “quão produtiva é essa equipe?”. Esse número é citado nas reuniões de status, depois comparado entre as equipes e, por fim, torna-se uma meta a ser atingida. Em dois sprints, a equipe já reajustou o tamanho de suas tarefas para fazer o número subir — agora, cada história tem um tamanho 30% maior do que antes — e a velocidade deixou de ter o significado que tinha antes. A previsão que deveria ser gerada agora está errada.

O segundo: comparar equipes. Duas equipes que estimam o mesmo backlog apresentam números de velocidade diferentes porque utilizam histórias de referência distintas — esse é justamente o objetivo da estimativa relativa. Compará-las é como comparar dois termômetros com pontos zero diferentes. Os números não têm o mesmo significado, e tratá-los como se tivessem corrompe a calibração de ambas as equipes.

Quando fazer uma nova estimativa

Reavaliar o trabalho já concluído prejudica a velocidade. Reavaliar o trabalho acumulado é o único caso em que se age com honestidade.

A pergunta surge a cada trimestre: “avaliamos isso como um 5, mas na verdade era um 13 — devemos atualizar?” O instinto que diz que sim é o mesmo que quer que todos os números estejam corretos retroativamente, e isso está errado. A velocidade é a taxa na qual a equipe — com a calibração que tinha naquele momento — concluiu o trabalho. Voltar atrás e reescrever os pontos reescreve a calibração também, e a previsão que antes funcionava deixa de funcionar. “A equipe ficou mais rápida, então as histórias antigas deveriam ser menores” remove o único sinal de que a equipe melhorou. “Esse 5 acabou sendo um 13” é um sinal de refinamento para dimensionar a próxima história semelhante, não uma permissão para reescrever o histórico desta.

O único caso em que você deve refazer a estimativa é o de trabalho remanescente. Uma história não foi concluída, o sprint está chegando ao fim e o trabalho restante passa a fazer parte do compromisso do próximo sprint. Esse trabalho restante é substancialmente diferente do que foi dimensionado no início — a equipe já realizou parte dele, identificou pelo menos uma incógnita e tem uma visão mais clara do que ainda falta. Faça uma nova votação como se fosse um item novo, usando a estimativa original como uma verificação de plausibilidade, e não como uma restrição.

Normalização da velocidade entre as equipes

A normalização é, em grande parte, um ritual do SAFe para garantir que os números do painel do portfólio batam. Evite fazê-la, a menos que alguém em uma posição hierárquica superior à sua realmente precise desse painel.

A normalização faz com que duas ou mais equipes cheguem a um acordo sobre uma referência comum — geralmente algo como “um dia-pessoa de trabalho para um engenheiro médio” — de modo que um 5 na Equipe A signifique a mesma coisa que um 5 na Equipe B, e suas velocidades possam ser somadas. A técnica funciona: um 5 normalizado realmente significa a mesma coisa entre as equipes que concordaram com ele. O problema é o que você abriu mão em troca disso. Você trocou a propriedade de estimativa relativa de cada equipe por uma absoluta — o que é uma estimativa de duração disfarçada — apenas para que um número possa ser calculado como média entre equipes que não compartilham uma base de código, uma pilha de tecnologias ou um domínio.

Se uma previsão no nível do portfólio realmente financia o trabalho (e não serve apenas para comparar equipes), faça a normalização na camada de consolidação: peça à gestão do programa que mantenha um multiplicador de pontos por equipe, calibrado uma vez e revisado raramente, e aplique-o quando os números forem consolidados. Cada equipe continua fazendo suas estimativas com base em sua própria história de referência; o multiplicador transforma a velocidade da equipe na moeda do portfólio, e as reuniões de refinamento nunca têm acesso a ele. O que deve ser evitado: a normalização que começa dentro de uma única equipe e a normalização feita para facilitar a comparação entre equipes. Essa segunda opção não é um caso de uso — é um antipadrão com um nome sofisticado.

Ferramentas de programação Velocity e IA

Copilot, Cursor, Claude Code. Os pontos não mudam. A velocidade é que muda — e só depois do fato.

Essa dúvida surge em todas as equipes que utilizam um assistente de programação com IA há alguns meses: estamos lançando produtos mais rapidamente, será que devemos reavaliar o backlog? Será que o 3 do último trimestre deveria ser um 5 neste trimestre? A resposta é não, porque os pontos de história nunca mediram o que realmente mudou. Os pontos medem a complexidade relativa e a incerteza; o assistente reduz o tempo de digitação em uma história, às vezes drasticamente, mas a complexidade permanece a mesma, as incógnitas permanecem as mesmas, o risco de integração e os casos extremos permanecem os mesmos. Não reclassifique um 5 para um 3 só porque a ferramenta escreveu o código padrão e você está estimando em horas novamente.

O que muda é a velocidade. A mesma equipe que entrega o mesmo tipo de trabalho com um assistente entrega mais pontos por sprint do que entregava há seis meses — não porque os pontos tenham diminuído, mas porque a equipe ficou mais rápida em transformar pontos em código entregue. Esse é o número cumprindo exatamente sua função, e ele se reajusta naturalmente ao longo de três ou quatro sprints. Mantenha a história de referência da equipe atualizada — uma que tenha sido entregue com as ferramentas que usam agora — e a calibração já levará em conta qualquer aumento de velocidade que exista.

Há dois pontos que merecem ser questionados. A afirmação “A velocidade aumentou 30%, vamos nos comprometer com mais 30%” conta duas vezes a melhoria: a média recente já inclui o efeito da IA, portanto, não a amplie novamente. “Tudo ficou menor, vamos reavaliar o backlog” é a armadilha da reavaliação mencionada acima — as histórias não diminuíram, a equipe ficou mais rápida, e a previsão já reflete isso. É na incerteza que as ferramentas ajudam menos: um assistente agiliza partes de uma investigação [de um spike],/guides/agile-estimation-guide/splitting-user-stories/ mas o que o spike está tentando aprender não ficou menor.

Perguntas frequentes

Quantos pontos de história por sprint é considerado normal?

Não existe um número padrão no setor. A velocidade é a produtividade medida da sua equipe — a média móvel de pontos concluídos nos últimos sprints. Quinze, quarenta, cem: nenhum desses números é certo ou errado, pois cada um é calibrado com base em uma história de referência diferente.

Quantos pontos de história por sprint por desenvolvedor?

Não calcule isso individualmente. Uma taxa por desenvolvedor transforma os pontos de história novamente em horas disfarçadas e incentiva a comparação entre pessoas — algo que a técnica visa evitar. A velocidade é um número da equipe, não a soma de cotas individuais.

Quantos pontos de história há em um sprint de duas semanas?

Independentemente do número de histórias que sua equipe tenha concluído historicamente em um sprint de duas semanas — avalie esse número, mas não o use como meta. Escolha histórias até que elas totalizem aproximadamente 80 a 90% da sua média recente e deixe margem para imprevistos.

Qual é uma boa velocidade para uma equipe de Scrum?

Uma velocidade estável. “Nossa velocidade está boa?” é a pergunta que desestabiliza o sistema — no momento em que a velocidade é avaliada, os números aumentam artificialmente e, na verdade, nada é entregue mais rápido. Uma boa velocidade é aquela com a qual se pode planejar, não um número que não para de subir.

Leituras relacionadas