Velocity e burndown, as métricas que mais aparecem no Jira por padrão, são as que mais enganam o gestor sobre produtividade real. Velocity mede esforço estimado em story points, não valor entregue, e não serve para comparar times.

Burndown esconde onde o trabalho trava. O que revela a saúde da entrega são as métricas de fluxo: lead time, cycle time, throughput e WIP. Elas trocam a pergunta “quão ocupado o time está?” pela pergunta que importa: “com que rapidez e previsibilidade entregamos valor?”

Por que velocity não mede produtividade

Velocity é a soma de story points concluídos por sprint. É útil para uma coisa só: prever, de forma aproximada, quanto cabe em uma sprint futura, com base no histórico do próprio time. Fora disso, ela engana de três formas.

•     Mede esforço, não resultado. Story point é complexidade estimada. Concluir muitos pontos não significa ter entregue algo que o usuário queria.

•     Não compara times. Pontos são relativos a cada time. Os 30 pontos de um não equivalem aos 30 de outro, porque cada um estima de um jeito.

•     Infla com facilidade. Quando velocity vira meta de desempenho, o time aprende a estimar mais alto. O número sobe, a entrega real não.

Regra prática: velocity é ferramenta de previsão de capacidade dentro de um time estável, não um placar de produtividade. No momento em que ela vira cobrança de gestão, deixa de medir o que você pensa que mede.

O que o burndown esconde

O gráfico de burndown mostra trabalho restante caindo ao longo da sprint. Parece transparência, mas é um resumo que apaga o detalhe mais importante: onde o trabalho está parado. Uma linha que desce devagar não diz se o time está sobrecarregado, se há tarefas presas em revisão ou se uma dependência externa travou tudo. Para enxergar isso, você precisa de métricas que olham o fluxo, não o saldo.

Quais métricas de fluxo olhar

As quatro métricas de fluxo formam um conjunto. Nenhuma sozinha conta a história inteira, e é a leitura combinada que revela a verdade.

 Métrica: Lead time

O que mede: Tempo do pedido até a entrega ao usuário

O que revela: Quanto o cliente realmente espera, incluindo o tempo na fila antes de começar

Métrica: Cycle time

O que mede: Tempo do início do trabalho ativo até a conclusão

O que revela:Eficiência interna do time; se sobe, há WIP demais, dependências ou gargalo

Métrica: Throughput

O que mede: Itens concluídos por período

O que revela: Volume de entrega real, contado em itens finalizados, sem peso de estimativa

Métrica: WIP

O que mede: Itens em andamento ao mesmo tempo

O que revela: Sobrecarga e troca de contexto; WIP alto estica o lead time

Essas quatro métricas são as que a própria Atlassian recomenda para acompanhar eficiência de fluxo no Jira, e a relação entre elas não é opinião: pela Lei de Little, throughput é igual a WIP dividido por cycle time. Reduzir o WIP reduz o cycle time.

É por isso que limitar o trabalho em andamento, em vez de começar tudo ao mesmo tempo, acelera a entrega real.

Como configurar isso no Jira

O Jira já traz relatórios de fluxo prontos. Cycle time e lead time aparecem em scatterplots de tempo de ciclo, o WIP é visualizado pelo diagrama de fluxo cumulativo (CFD), e o throughput sai da contagem de itens concluídos por período. O diagrama de fluxo cumulativo é especialmente útil: bandas que incham em um estágio do board apontam acúmulo de WIP e gargalo naquele ponto.

O ponto onde a maioria dos times tropeça não é a ferramenta, é a configuração: estados do workflow mal definidos produzem métricas de fluxo enganosas. Se a coluna “em progresso” mistura trabalho ativo com trabalho parado esperando revisão, o cycle time mente. Calibrar o board para que cada coluna represente um estado real do fluxo é o trabalho técnico que transforma o dado em decisão.

Quando velocity ainda é útil

Velocity não é inútil, é mal usada. Dentro de um time estável, com a mesma composição ao longo de várias sprints, o histórico de velocity é uma base razoável para conversar sobre o que cabe em uma sprint ou release futura. O erro é tratá-la como medida de produtividade ou como instrumento de comparação entre times. Usada como previsão, e não como placar, ela cumpre seu papel.

Perguntas frequentes

Qual a diferença entre lead time e cycle time?

Lead time começa quando o pedido é feito; cycle time começa quando o trabalho ativo de fato inicia. O cliente costuma se importar com o lead time, ou seja, com a espera total. O time usa o cycle time para melhorar o próprio processo interno. A diferença entre os dois revela quanto tempo o trabalho passa apenas esperando na fila.

Throughput é a mesma coisa que velocity?

São parecidos, mas não iguais. Throughput conta itens concluídos, sem ponderar tamanho. Velocity soma story points, que carregam estimativa. Throughput é menos manipulável porque conta entrega concreta, não esforço estimado.

Limitar o WIP não deixa o time mais lento?

É o contrário. Pela Lei de Little, WIP alto aumenta o cycle time de forma proporcional. Começar muita coisa ao mesmo tempo gera troca de contexto e faz tudo ficar “quase pronto” sem nada terminar. Limitar o WIP faz o trabalho fluir e a entrega acelerar.

Preciso trocar de ferramenta para medir fluxo?

Não. O Jira já oferece os relatórios de cycle time, lead time, throughput e o diagrama de fluxo cumulativo. O que costuma faltar é a configuração correta do workflow para que esses números reflitam o fluxo real, não estados mal desenhados do board.

Próximo passo

Se o seu board do Jira mostra velocity subindo mas a entrega não acompanha, o problema provavelmente está em o que você mede, não em quanto o time trabalha. Fale com um especialista CSP em métricas ágeis no Jira e configure o board para medir fluxo, não esforço.

Autor: Guilherme Matos, estrategista de conteúdo e IA, certificado HubSpot, Google e Anthropic. CSP Tech, Atlassian Gold + Microsoft Gold Partner, Rising Star Team’22.

Fontes: Atlassian, “4 Kanban Metrics You Should Be Using Right Now” (atlassian.com); Scrum.org, “4 Key Flow Metrics”; Agile Alliance, “Metrics for Understanding Flow”; Lei de Little aplicada a fluxo ágil (acesso jun/2026).