Velocity no Ágil: Como Medir o Throughput da Equipe
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
A velocity ágil é um dos números mais práticos que uma equipe Scrum pode acompanhar. Ela informa, em média, quanto trabalho sua equipe realmente conclui em uma sprint, o que é a base de qualquer previsão honesta de lançamento ou plano de capacidade.
A maioria das equipes ouve falar de velocity no início de sua jornada ágil, a usa de forma equivocada como uma pontuação de desempenho, e depois se pergunta por que isso cria pressão em vez de clareza. Este guia explica o que é velocity, como calculá-la corretamente e como usá-la como ferramenta de previsão sem manipular o número.
O Que É Velocity no Ágil?
Velocity ágil é o número médio de story points que uma equipe conclui em uma sprint. É calculada dividindo o total de pontos concluídos em várias sprints recentes pelo número dessas sprints.
Essa é a definição completa. Velocity não mede qualidade, rapidez, eficiência ou esforço. Ela mede o throughput concluído em uma janela de tempo fixa, nada mais.
A palavra-chave é "concluído". Story points que foram iniciados mas não terminados antes do fim da sprint não contam para a velocity. Não existe crédito parcial aqui. Esse rigor é o que torna a velocity um insumo de previsão confiável: se uma equipe tem uma velocity média de 42 pontos, você pode projetar sprints futuras com confiança razoável porque o número reflete o que realmente foi entregue, não o que foi tentado.
Principais Fatos
- Equipes que acompanham a velocity por pelo menos 6 sprints produzem estimativas de data de lançamento 40% mais precisas do que equipes que estimam puramente por instinto (Scrum Alliance State of Scrum, 2023).
- A velocity média de uma equipe Scrum varia de 20 a 60 story points por sprint, embora o número em si seja menos importante do que sua estabilidade ao longo do tempo (VersionOne State of Agile, 2023).
- Aproximadamente 60% das equipes ágeis relatam usar a velocity como sua principal métrica de planejamento de capacidade, tornando-a a medida de throughput mais amplamente adotada no Scrum (Digital.ai State of Agile Report, 2023).
Como Calcular a Velocity
A fórmula é direta.
Velocity = Total de story points concluídos / Número de sprints medidas
Use as últimas 3 a 5 sprints para uma média móvel. Menos de 3 sprints dá uma visão ruidosa; mais de 7 começa a misturar dados de períodos em que a equipe tinha uma composição diferente ou hábitos de estimativa diferentes.
Aqui está um exemplo prático para uma equipe rodando sprints de 2 semanas:
| Sprint | Pontos Comprometidos | Pontos Concluídos |
|---|---|---|
| Sprint 1 | 48 | 42 |
| Sprint 2 | 45 | 44 |
| Sprint 3 | 50 | 39 |
| Sprint 4 | 46 | 45 |
Velocity média móvel (4 sprints): (42 + 44 + 39 + 45) / 4 = 42,5 pontos
A velocity de trabalho da equipe é de aproximadamente 42 pontos por sprint. Note que o número comprometido não importa para o cálculo. O que importa é o que cruzou a linha de "concluído" antes do fim da sprint. Se a Sprint 3 parece baixa, investigue a causa (mudança de escopo? bloqueio no meio da sprint? feriado?) em vez de descartá-la ou inflá-la.
Como Usar a Velocity para Previsão
Uma vez que você tem uma velocity estável, pode responder à pergunta que todo stakeholder eventualmente faz: "Quando isso vai ficar pronto?"
A abordagem é simples. Some os story points do seu backlog restante (ou a fatia do backlog para um lançamento específico) e divida pela sua velocity média.
Sprints até a conclusão = Pontos restantes do backlog / Velocity média
Digamos que sua equipe tenha 210 pontos restantes em um backlog de lançamento e uma velocity de 42. Isso são 5 sprints, ou 10 semanas em um ritmo de 2 semanas. Essa é sua previsão.
Algumas práticas tornam isso mais útil na prática:
- Use uma faixa, não uma estimativa pontual. Aplique o resultado da sua sprint recente mais baixa e o da mais alta para obter uma faixa de confiança. "Entre 4,5 e 6 sprints" é mais honesto do que "exatamente 5".
- Refaça a previsão a cada sprint. Conforme a equipe conclui trabalho, adiciona novos itens ou remove escopo, a projeção muda. Trate-a como um número vivo, não um contrato.
- Conecte a velocity ao seu hábito de refinamento de backlog. As previsões de velocity só são tão boas quanto o sprint planning que mantém o backlog dimensionado e ordenado. Se as estimativas derivarem ou o backlog ficar desatualizado, a velocity perde seu poder de previsão.
- Vincule-a aos marcos do roadmap. Se seu roadmap diz que uma funcionalidade será lançada no Q3, trabalhe de trás para frente a partir do prazo para ver quantas sprints você tem, multiplique pela velocity e verifique se o escopo restante cabe. Se não couber, você tem uma conversa sobre escopo ou prazo para ter cedo, não no prazo final.
Esse método de previsão também funciona bem com o planning poker, que ajuda a manter as estimativas de story points calibradas em toda a equipe para que a velocity continue significativa ao longo do tempo.
O Que a Velocity NÃO É
É aqui que a maioria das equipes erra.
Velocity não é uma métrica de produtividade. Uma equipe com velocity de 60 não é "melhor" do que uma equipe com velocity de 30. Story points são relativos à escala própria de cada equipe. Uma equipe pode dimensionar uma funcionalidade em 8 pontos; outra pode dimensionar a mesma funcionalidade em 3. Não existe uma unidade compartilhada. Comparar velocities entre equipes não tem sentido.
Velocity não é uma meta a aumentar. Quando gestores definem "melhorar a velocity em 20%" como objetivo, as equipes fazem exatamente uma coisa previsível: inflam suas estimativas de story points. O número sobe, mas o resultado real não muda. Você acabou de degradar a calibração do seu sistema de estimativa.
Velocity não é uma medida de desempenho individual. A velocity pertence à equipe, não a nenhuma pessoa específica. Usá-la para avaliar indivíduos cria os incentivos errados e quebra a estimativa colaborativa que torna a métrica precisa.
Velocity não é um compromisso. Os stakeholders às vezes tratam a velocity como um piso: "Vocês fizeram 44 pontos na última sprint, então estão comprometidos com pelo menos 44 nesta sprint." Não é assim que funciona. Velocity é uma média histórica usada para planejamento, não uma obrigação de throughput mínimo.
Fatores Que Afetam a Velocity
A velocity muda com o tempo, e a maioria dessas mudanças tem causas óbvias. Saber o que impulsiona a variação ajuda você a interpretar os números em vez de reagir a eles.
Mudanças na composição da equipe. Quando uma nova pessoa entra, a velocity normalmente cai por 2 a 3 sprints enquanto ela se adapta. Quando alguém sai, o efeito é imediato. Nenhuma das duas mudanças significa que a equipe está falhando.
Feriados e folgas. Uma sprint que abrange um feriado nacional ou tem várias pessoas de férias produzirá velocity mais baixa. Algumas equipes ajustam sua capacidade de sprint de acordo; outras simplesmente anotam isso ao revisar a média.
Mudanças de escopo no meio da sprint. Trazer trabalho não planejado ou trocar histórias no meio de uma sprint quebra a relação entre o que foi planejado e o que foi concluído. Essa é uma razão pela qual os limites de WIP importam: limitar o trabalho em andamento protege a sprint de interferências no meio do caminho.
Deriva de estimativa. Ao longo de meses, as equipes às vezes mudam inconscientemente a forma como dimensionam o trabalho. Uma "história de 5 pontos" no primeiro mês pode parecer uma "história de 3 pontos" no sexto mês, conforme a equipe fica mais rápida em trabalhos similares. Se a velocity tende a subir de forma constante sem nenhuma mudança no tamanho da equipe ou nas ferramentas, verifique se as estimativas derivaram em vez de presumir que a equipe está genuinamente mais rápida.
Dívida técnica e atrito ambiental. Pipelines de CI lentos, incidentes frequentes em produção e problemas de qualidade de código consomem capacidade de sprint sem aparecer no backlog. Equipes que carregam dívida técnica significativa costumam ter velocity mais baixa e mais variável do que sua capacidade sugeriria.
Velocity vs Outras Métricas de Fluxo
Velocity é uma métrica de nível de sprint. Ela informa sobre o throughput em janelas de tempo fixas. Mas não conta tudo sobre como o trabalho flui pelo seu sistema.
| Métrica | O Que Mede | Melhor Para |
|---|---|---|
| Velocity | Story points concluídos por sprint | Previsão de lançamento, capacidade de sprint |
| Diagrama de fluxo cumulativo | Contagem de itens de trabalho entre estágios do workflow ao longo do tempo | Identificar gargalos, crescimento de WIP, estabilidade de fluxo |
| Limites de WIP | Máximo de itens simultâneos em um estágio | Otimização de throughput, redução de troca de contexto |
| Tempo de ciclo | Tempo do início à conclusão por item | Previsibilidade no nível do item |
| Gráfico de burndown | Trabalho restante dentro de uma sprint ou lançamento | Saúde da sprint em tempo real |
Velocity e diagramas de fluxo cumulativo são complementares. A velocity dá o número de previsão em nível de sprint; o CFD mostra se seu workflow é saudável o suficiente para sustentá-la. Uma equipe com boa velocity mas um CFD instável (bandas de WIP crescendo, cruzamentos frequentes de bandas) está caminhando para uma queda de velocity.
Como Melhorar (Estabilizar) a Velocity
O objetivo não é maximizar a velocity. É tornar a velocity previsível, para que suas previsões sejam confiáveis. Veja como chegar lá.
Rode sprints consistentes. Durações de sprint variáveis (alternando entre 1 semana e 2 semanas) tornam os dados de velocity incomparáveis. Escolha um ritmo e mantenha-o por pelo menos 6 sprints antes de tirar conclusões.
Complete a definição de pronto antes de fechar as histórias. Se a definição de pronto da sua equipe é vaga, as histórias cruzam a linha de "concluído" em níveis de qualidade diferentes, tornando os pontos incomparáveis. Refine a definição e a aplique.
Proteja a sprint de trabalho não planejado. Todo incêndio no meio da sprint que tira um desenvolvedor de foco atinge diretamente a velocity. Construa um processo leve de triagem (um filtro do product owner, uma regra de "emergência") que direcione itens urgentes sem quebrar os compromissos da sprint.
Mantenha as estimativas calibradas. Faça um breve exercício de recalibração a cada trimestre. Pegue de 5 a 10 histórias concluídas e reestime-as com a equipe atual. Se as novas estimativas diferirem significativamente das originais, seus dados de velocity de antes da mudança precisam de um ajuste mental.
Rastreie as causas de sprints atípicas. Quando a velocity dispara ou cai mais de 20% em relação à média móvel, anote a causa na sua retrospectiva de sprint. Padrões se tornam visíveis: se sprints de feriado consistentemente caem 25%, você pode incorporar isso ao planejamento de capacidade.
Use o refinamento de backlog de forma consistente. Itens de backlog não refinados produzem estimativas pouco confiáveis, o que produz velocity ruidosa. Equipes que refinam regularmente mantêm velocity mais estável porque trabalham a partir de histórias bem compreendidas e dimensionadas corretamente.
Reduza a instabilidade de escopo. Mudanças frequentes de escopo no meio da sprint são o maior fator individual de instabilidade de velocity para a maioria das equipes. Sprints estáveis com mudança mínima de escopo produzem velocity estável.
Perguntas Frequentes
Quantas sprints de dados eu preciso antes que a velocity seja confiável? A maioria dos praticantes recomenda pelo menos 5 a 6 sprints concluídas antes de tratar a velocity como um insumo de previsão. Antes disso, você está olhando para uma amostra pequena demais para filtrar o ruído. Durante as primeiras sprints, trate a velocity como direcional, não preditiva.
E se nossa velocity mudar drasticamente de sprint para sprint? Alta variância geralmente sinaliza uma dentre algumas coisas: duração de sprint inconsistente, mudanças frequentes de escopo no meio da sprint, uma equipe recém-alterada, ou deriva de estimativa. Comece registrando a causa de cada sprint atípica na sua retrospectiva. Uma vez que você consegue explicar a variação, pode abordar a causa raiz em vez de apenas tirar a média em torno do ruído.
Devemos compartilhar a velocity com os stakeholders? Compartilhe a previsão de lançamento, não o número bruto. Stakeholders que veem o número de velocity isoladamente costumam tratá-lo como uma meta ou um benchmark contra outras equipes. A previsão ("este lançamento está no caminho certo para o Q3 com base no ritmo atual") dá a eles o que precisam sem criar a pressão errada.
Podemos usar velocity sem story points? Sim. Algumas equipes acompanham a velocity em contagem de histórias em vez de pontos, o que funciona se suas histórias forem consistentemente similares em tamanho. Outras usam tamanhos de camiseta convertidos em uma escala numérica. O importante é que qualquer unidade usada permaneça consistente por tempo suficiente para construir uma média significativa.
Como a velocity é diferente da capacidade? Capacidade é a disponibilidade planejada (total de horas da equipe em uma sprint). Velocity é o throughput real (pontos concluídos). Capacidade é insumo; velocity é resultado. As equipes às vezes usam a capacidade para definir uma meta de sprint, mas usam a velocity para prever lançamentos futuros. Confundir as duas leva a comprometimento excessivo: uma sprint em 100% de capacidade não garante que 100% dos pontos planejados serão concluídos.
Velocity é um número simples, mas as equipes tiram o máximo proveito dela quando param de persegui-la e começam a interpretá-la. Uma velocity estável significa que seus hábitos de estimativa e entrega são consistentes o suficiente para planejar em torno deles. Quando a velocity muda, isso é informação: algo no ambiente ou processo da equipe mudou, e vale a pena entender o quê.
Combine-a com a disciplina de sprint planning, estimativas limpas de story points e visibilidade de fluxo do seu diagrama de fluxo cumulativo, e você terá um sistema de previsão em que os stakeholders realmente podem confiar.
