GUIA
Velocity: O Que É e Por Que Importa
Uma métrica de fluxo central — quantos itens um time de fato termina por período, não quantos ele começou.
O que mede
Velocity é uma contagem de trabalho concluído: quantos itens um time terminou num período dado, dia a dia ou semana a semana. Parece próximo de throughput, e no pensamento baseado em fluxo é basicamente a mesma ideia — a diferença pra o "velocity" antigo, baseado em story points, é que essa versão conta item terminado, não esforço estimado, então não dá pra inflar reestimando o mesmo backlog pra maior.
Por que importa
Velocity é o número que transforma "o time parece ocupado" em "o time está de fato terminando coisa". Ocupado e produtivo não são a mesma coisa — um time pode ter WIP alto, horas longas e troca de contexto constante enquanto entrega muito pouco, porque a atenção está espalhada demais entre trabalho não terminado. Velocity é o contrapeso: só credita trabalho que cruzou a linha de chegada, que é o que um roadmap, um stakeholder ou um cliente de fato sente.
Também é o número que torna as outras métricas de fluxo acionáveis juntas, não isoladas. Um WIP subindo com velocity parado é um sinal específico e útil — significa que mais coisa está sendo começada do que terminada, e o cycle time está prestes a piorar antes mesmo de aparecer na média. Vistas sozinhas, nem cycle time, nem WIP, nem velocity contam a história inteira; vistas juntas, elas se explicam.
Como calcular
Conta os itens com timestamp de conclusão dentro do período, e marca a contagem por dia ou por semana. A única decisão que muda o número de verdade: o que conta como "concluído" — a definição mais limpa é a primeira vez que um item chega num status que seu time classificou como concluído, não a última (um item que reabre e é refeito não deveria contar duas vezes só porque cruzou a linha de chegada mais de uma vez).
Como interpretar o número
Diferente das 4 métricas DORA, as métricas de fluxo não têm um benchmark de mercado "elite vs. típico" amplamente publicado — tamanho de time, granularidade de item de trabalho e o que conta como "um item" variam demais entre times pra um número universal significar muita coisa. A comparação útil é um time contra o próprio histórico recente, não contra o velocity de outro time: uma tendência estável ou melhorando ao longo de várias semanas importa mais que a contagem absoluta de uma semana só, e uma queda repentina vale a pena investigar (menos gente, itens maiores, ou trabalho travando mais cedo no pipeline) antes de assumir que é um problema de motivação.
Uma armadilha comum
Comparar velocity entre times quase sempre produz a conclusão errada, porque "um item" significa algo diferente em cada board — um time que quebra o trabalho em tickets pequenos vai mostrar um velocity maior que um que abre poucos itens grandes, sem de fato entregar mais. Velocity é uma métrica de tendência pra um time só ao longo do tempo, não um ranking entre times.
Como o moasy.tech calcula isso
O moasy.tech recalcula o velocity automaticamente a partir do histórico de conclusão já sincronizado do Jira e Linear — somente leitura, sem contagem manual, com uma quebra dia a dia mostrada ao lado do WIP e do cycle time, pra os três contarem uma história só e conectada em vez de três gráficos separados.
Veja as outras métricas de fluxo no guia completo, ou a implementação completa na página de Flow Metrics.
Dado ilustrativo, apenas para demonstração.
Perguntas sobre velocity
É a mesma coisa que "velocity" no Scrum, medido em story points?
Não — velocity em story points mede esforço estimado, algo específico do hábito de estimativa de cada time e fácil de inflar reestimando. Esse velocity conta item terminado diretamente, o que é comparável ao longo do tempo pro mesmo time sem depender de precisão de estimativa.
A gente deveria definir uma meta de velocity?
Cuidado com isso — uma meta tende a mudar o que é marcado como "concluído" muito antes de mudar a velocidade real do trabalho. Acompanhar a tendência em busca de uma mudança real e sustentada é mais confiável do que perseguir um número.
Por que o velocity caiu mesmo o time não tendo diminuído?
Confira o WIP e o cycle time de algumas semanas antes primeiro — uma queda de velocity é muitas vezes o resultado atrasado de começar coisa demais de uma vez, não um sinal de que o time está trabalhando menos.
Veja seu próprio velocity
Começar grátis