Velocidade da equipe no ágil: como medi-la e utilizá-la (+ calculadora gratuita)

A velocidade da equipe é um dado de entrada 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 de pontos de história que uma equipe conclui por sprint, calculada com base 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 fará isso, estimando o mesmo trabalho como maior, em vez de realizar mais trabalho. Essa é a lei de Goodhart em ação em um ciclo de duas semanas.

Uma observação importante antes do passo a passo: o Guia do Scrum não menciona a velocidade. Trata-se de uma prática comum aplicada em conjunto com o Scrum, e não uma regra do método, e é exatamente por isso que vale a pena refletir cuidadosamente sobre para que você a utiliza.

Como calcular a velocidade da equipe

Some os pontos alcançados em cada um dos últimos três a cinco sprints. Calcule a média. Esse é o seu índice de velocidade.

Um exemplo prático, ao longo de três sprints:

Sprint	Pontos de história concluídos
Sprint 7	21
Sprint 8	34
Sprint 9	26

Velocidade = (21 + 34 + 26) dividido por 3 = 27 pontos por sprint.

Se a carteira de trabalhos tiver 210 pontos restantes, a previsão é de 210 dividido por 27, o que equivale a cerca de 8 sprints. Como os valores inseridos variaram de 21 a 34, a versão correta é “sete a dez sprints”, e não “7,8 sprints”. Ou pule a conta e deixe a calculadora acima fazer isso por você.

As regras que garantem a precisão do número: não faça ajustes para sprints “excepcionais”, pois esses sprints fazem parte do sinal que você está tentando suavizar. Não conte duas vezes o trabalho acumulado e não conte, de forma alguma, as histórias parcialmente concluídas. Elas só contam no sprint em que forem realmente concluídas. Quanto mais simples for o cálculo, mais difícil será burlá-lo.

A velocidade se estabiliza depois que uma equipe já vem trabalhando em conjunto por três ou quatro sprints. Uma nova equipe, uma nova história de referência ou uma grande mudança no quadro de pessoal são 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 dessa equipe nesse período específico. Uma equipe que perdeu dois membros ontem tem a velocidade de ontem, que agora se refere a uma equipe diferente.

Usando a velocidade para planejar o próximo sprint

O Velocity mostra seu valor no planejamento de sprints, e o método é breve:

1. Comece pela média móvel dos últimos três a cinco sprints, nunca pelo resultado de um único sprint e nunca pelo seu melhor sprint.
2. Leve em conta as mudanças conhecidas na capacidade. Duas pessoas de licença no próximo sprint? Um feriado? Reduza a meta proporcionalmente antes do planejamento, e não como uma medida de compensação depois. A velocidade é calculada com base na equipe que a produziu, e a equipe do próximo sprint às vezes é menor.
3. Comprometa-se com um volume abaixo da média, algo em torno de 80% a 90% dela. Selecione as tarefas até que somem aproximadamente esse valor e reserve uma margem para o trabalho não planejado que surge a cada sprint, independentemente de você ter planejado ou não.
4. Faça previsões em intervalos. Para qualquer coisa além do próximo sprint, indique seus melhores e piores sprints recentes como limites. As partes interessadas podem se planejar com base em “sete a dez sprints”. Elas não podem se planejar com base em um número preciso que acabe se revelando errado.

Use a velocidade para fazer três coisas, e apenas três: estimar uma data para um escopo conhecido (o escopo dividido pela velocidade resulta no número de sprints), decidir o que cabe no próximo sprint e identificar quando algo mudou (uma queda de 30% é um sinal que justifica uma conversa na retrospectiva de sprint). 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, apenas com uma roupagem 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.

O grande erro: a velocidade como indicador de desempenho

O principal motivo de falha: um gerente interpreta o valor da velocidade como “quão produtiva é essa equipe?”. Esse número é citado nas reuniões de status, comparado entre as equipes e, então, passa a ser uma meta a ser atingida. Em dois sprints, a equipe já reajustou o tamanho das 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. A previsão que deveria ser gerada agora está errada.

O segundo: comparar equipes. Duas equipes que avaliam o mesmo backlog apresentam números de velocidade diferentes porque utilizam histórias de referência distintas, e 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.

Quer que façamos os cálculos para você? Volte para a calculadora de velocidade gratuita e faça seus próprios sprints com ela.

Quando fazer uma nova estimativa

Reavaliar o trabalho 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 costumava funcionar 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 um imprevisto 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 história de referência comum, geralmente algo como “um dia-pessoa de trabalho para um engenheiro médio”; assim, um 5 na Equipe A significa a mesma coisa que um 5 na Equipe B, e suas velocidades podem 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 reajustar o backlog? O valor 3 do último trimestre deveria ser 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 uma reflexão. 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 multiplique novamente. “Tudo ficou menor, vamos reestimar o backlog” é a armadilha da reestimativa 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, mas o que o spike está tentando aprender não ficou menor.

Faça a estimativa em conjunto no TeamRetro

A precisão do Velocity depende da qualidade das estimativas em que se baseia. O TeamRetro Estimations realiza o planning poker com sua equipe, seja em tempo real ou de forma assíncrona, de modo que os pontos inseridos nesta calculadora refletem a avaliação de toda a equipe, e não a suposição de uma única pessoa. Experimente o TeamRetro Estimations ou comece com a ferramenta gratuita de planning poker.

Perguntas frequentes

O que é a velocidade da equipe na metodologia ágil?

A velocidade da equipe é a média de pontos de história que uma equipe conclui por sprint, geralmente calculada com base nos últimos três a cinco sprints. Trata-se de um dado de planejamento, utilizado para prever o volume de trabalho que pode ser incluído no próximo sprint e o tempo que levará para concluir o backlog, e não uma medida do desempenho da equipe.

Como se calcula a velocidade da equipe?

Some os pontos de história concluídos em cada um dos últimos três a cinco sprints e calcule a média. Se nos seus últimos três sprints foram concluídos 21, 34 e 26 pontos, sua velocidade é 27. Conte apenas as histórias concluídas, no sprint em que foram concluídas, ou use a calculadora gratuita nesta página para fazer os cálculos.

O que é uma boa velocidade de equipe?

Uma velocidade estável. Não existe um padrão de referência, pois os pontos de cada equipe são calibrados de acordo com seu próprio histórico de referência; portanto, 15, 40 e 100 podem ser valores saudáveis. Uma boa velocidade é aquela com base na qual você pode planejar, e não um número que não para de subir.

Deve-se comparar a velocidade entre as equipes?

Não. Equipes diferentes calibram os pontos com base em histórias de referência diferentes, de modo que suas velocidades não estão nas mesmas unidades. Compará-las é como comparar dois termômetros com pontos zero diferentes. A comparação entre equipes também pressiona as equipes a inflar as estimativas, o que prejudica as previsões que a velocidade se destina a produzir.

E se não fizéssemos a estimativa em pontos, mas, por exemplo, usássemos os tamanhos de camiseta?

Ainda é possível acompanhar uma produção aproximada, mas não dá para obter um valor real de velocidade diretamente a partir dos tamanhos de camiseta, pois os tamanhos não somam. Duas opções. Primeiro, mapeie os tamanhos para uma escala simples de pontos (por exemplo, XS = 1, S = 2, M = 3, L = 5, XL = 8), some o total de itens concluídos a cada sprint e considere o resultado como uma tendência aproximada, em vez de um número preciso. Ou, se seus itens costumam ter tamanhos semelhantes, conte a produtividade: o número de itens concluídos por sprint. Ambas as opções são mais aproximadas do que a velocidade baseada em pontos; portanto, interprete-as como uma orientação, e não como números decimais. Quando precisar de uma previsão real, reavalie o trabalho de curto prazo em pontos. Consulte nosso guia sobre tamanhos de camisetas para entender a conversão entre tamanhos e pontos.

Como contabilizamos o trabalho que não é registrado como itens quantificados?

A velocidade reflete apenas o trabalho que você realmente dimensiona e acompanha. Tickets de suporte, reuniões, interrupções e correções de bugs não quantificadas ainda consomem capacidade; portanto, se grande parte desse trabalho for invisível, sua velocidade parecerá menor do que o esforço real da equipe e suas previsões ficarão otimistas. Duas soluções honestas. Registre o trabalho recorrente não planejado como itens dimensionados, para que ele seja incluído na velocidade como tudo o mais. Ou reserve capacidade para ele abertamente, comprometendo-se com cerca de 80% a 90% da sua média e deixando o restante como Slack. Não atribua pontos retroativamente a trabalhos invisíveis apenas para fazer o número parecer maior, pois isso prejudica a calibração da qual a velocidade depende.

Como vocês lidam com o retrabalho no Velocity?

O retrabalho é um esforço real, mas reavaliar uma tarefa que já havia sido considerada concluída prejudica a velocidade. Trate o retrabalho como um trabalho novo: crie um novo item, avalie seu tamanho e contabilize-o no sprint em que for concluído. Não reabra a história original para reestimá-la. Se o retrabalho continuar surgindo, isso é um sinal de qualidade que merece ser discutido na retrospectiva, e não um ajuste na velocidade. A previsão só permanece precisa se cada ponto for contabilizado uma única vez, no sprint em que o trabalho foi efetivamente concluído.

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

Não existe um número padrão para o setor. A velocidade é a produtividade medida da sua equipe, a média móvel dos pontos concluídos nos últimos sprints. Quinze, quarenta, cem: nenhum desses valores é 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 foi projetada para 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?

Não importa quantas tarefas sua equipe tenha concluído historicamente em um sprint de duas semanas. Avalie esse número, mas não o use como meta. Selecione as histórias até que elas totalizem cerca de 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 prática, 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

• Pontos de história x horas: por que a conversão de pontos em horas é o modo de falha que a velocidade vem substituir.
• Planejamento de velocidade e capacidade: uso da velocidade para definir um compromisso realista para o sprint.
• O que é um gráfico de burndown?: como as equipes acompanham os pontos que se comprometeram a entregar em um sprint.
• Técnicas ágeis de estimativa: onde a velocidade se encaixa entre o planning poker, os pontos de história e as demais técnicas, e qual usar em cada situação.
• Guia de estimativa ágil: o conjunto completo de recursos sobre estimativa.
• Planning Poker gratuito para equipes ágeis: faça a estimativa dos pontos que compõem a velocidade.