A maioria dos líderes de engenharia sabe dizer o quanto o squad está ocupado. Poucos conseguem dizer quanto trabalho o squad realmente conclui e entrega em um período. Esse gap é exatamente o que a métrica de throughput resolve. A métrica de throughput mede o número de itens de trabalho que um time entrega em uma janela de tempo fixa, dando a você um sinal concreto sobre capacidade de entrega, não apenas sobre atividade. Sem ela, os compromissos do sprint viram chute, o planejamento de capacidade perde sentido e a confiança dos stakeholders vai embora sprint após sprint. Esta página cobre a definição, como medir, benchmarks, como melhorar e como o DevStats exibe tudo isso automaticamente.
Pontos principais
- A métrica de throughput conta o número de tarefas, histórias ou pull requests que um squad conclui em uma janela de tempo definida. Ela mostra se o pipeline de entrega está produzindo output de forma consistente e é a base de qualquer conversa honesta sobre capacidade com stakeholders ou liderança de produto.
- A fórmula é direta: Throughput = itens concluídos / período de tempo. Um squad saudável de cinco a oito engenheiros geralmente conclui entre 20 e 40 issues por sprint de duas semanas, mas isso varia bastante pelo tamanho do time, granularidade dos tickets e complexidade do código. Nenhum número é universalmente "bom" sem contexto.
- O erro mais comum dos times é confundir throughput com velocity. Velocity mede story points, que são estimativas subjetivas. Throughput conta itens concluídos de verdade, tornando-se um sinal mais objetivo e mais difícil de manipular sobre a saúde das entregas. Times que otimizam para velocity muitas vezes perdem o que o throughput revela sobre o output real.
- O DevStats rastreia sua métrica de throughput automaticamente conectando ao seu provedor Git e ao seu issue tracker, exibindo tendências comparadas a benchmarks de mais de 1.000 times de engenharia. Comece um teste gratuito e veja seus números em menos de dois minutos.
Definição de métrica de throughput
A métrica de throughput é a contagem de itens de trabalho que um time de engenharia de software conclui e entrega em um período de tempo específico, normalmente um sprint, uma semana ou um mês. É uma medida direta do output de entrega: quanto trabalho finalizado realmente sai do pipeline.
Tecnicamente, ela é expressa como: Throughput = itens concluídos / período de tempo. Os itens contados podem ser pull requests mergeados, issues fechadas ou user stories aceitas, dependendo de como o squad rastreia o trabalho. Você pode ver como o DevStats exibe isso na funcionalidade de throughput, que agrega itens concluídos nos repositórios e issue trackers conectados. Quando o throughput é estável e previsível, ele se torna um insumo confiável para planejamento de roadmap, decisões de contratação e previsão de releases.
Por que a métrica de throughput importa para times de engenharia
Quando os squads não rastreiam a métrica de throughput, o planejamento do sprint opera na intuição. Os times se comprometem além do que conseguem, entregam menos do que prometem e gastam as retros explicando o porquê em vez de melhorar a forma como trabalham. Gargalos invisíveis se acumulam nas filas de code review, nos estados de espera e nos tickets bloqueados. Nenhum deles aparece no burndown chart até ser tarde demais. A consequência não é só um sprint perdido: é a credibilidade corroída com stakeholders de produto e negócio, que precisam de sinais de entrega confiáveis para tomar decisões de investimento.
O throughput se conecta diretamente aos KPIs centrais do líder de engenharia. Throughput previsível permite compromissos precisos de roadmap. Throughput em queda é frequentemente um sinal precoce de burnout do squad, scope creep ou atrito de processo, antes que esses problemas virem problemas de retenção. Times que medem throughput de forma consistente também conseguem fazer trocas honestas entre trabalho de features e dívida técnica, porque têm uma baseline para raciocinar. Se você quiser ver como as DORA metrics do seu time se relacionam com as tendências de throughput, a conexão entre frequência de entrega e volume de output é um dos sinais mais claros na mensuração de engenharia de software.
Dentro do SPACE framework, o throughput está na dimensão de Performance: ele mede resultados, não atividade. Medi-lo é o primeiro passo. O que você faz com os dados é onde entra o seu julgamento como líder de engenharia.
Como medir a métrica de throughput
O throughput é calculado contando o número de itens de trabalho concluídos em uma janela de tempo definida. A janela de tempo importa: use um intervalo consistente, semanal ou por sprint, para que você possa comparar períodos de forma significativa. Suas fontes de dados são o issue tracker (Jira, Linear, GitHub Issues) para conclusões de histórias e tarefas, e o seu provedor Git (GitHub, GitLab, Bitbucket) para pull requests mergeados. Você não precisa de um pipeline de CI/CD para medir throughput, mas combiná-lo com dados de deploy dá uma visão mais completa de quanto trabalho concluído realmente chega à produção.
Não existe um benchmark publicado universalmente para throughput de engenharia da mesma forma que as DORA metrics definem deployment frequency, porque o throughput varia demais pelo tamanho dos tickets, tamanho do time e tipo de trabalho. A tabela abaixo descreve níveis qualitativos de desempenho com base em padrões observados em times de engenharia. Você pode comparar os números do seu squad com outros times usando os benchmarks do DevStats, extraídos de mais de 1.000 times de engenharia.
| Nível de desempenho | Benchmark de throughput | O que sinaliza |
|---|---|---|
| Elite | Output consistente e previsível semana a semana, com baixa variância | Processo estável, tickets bem dimensionados, poucos bloqueadores |
| Alto | Output majoritariamente consistente, com quedas ocasionais ligadas a eventos identificáveis | Bom fluxo com interrupções administráveis |
| Médio | Variância perceptível de sprint a sprint, output difícil de prever | Atrito de processo, dimensionamento inconsistente de tickets ou gargalos de review |
| Baixo | Output em queda ou errático ao longo de vários períodos | Bloqueadores sistêmicos, scope creep ou problemas de capacidade do squad que exigem investigação |
Os benchmarks variam pelo tamanho do time, maturidade do código e modelo de release. Um squad de três pessoas nunca vai igualar o output bruto de um squad de 12, mas a taxa de throughput por player é um ponto de comparação mais relevante.
A métrica de throughput na prática: um exemplo real
Uma VP de Engenharia em uma empresa SaaS de 45 pessoas percebeu que dois squads perdiam consistentemente os compromissos do sprint, mesmo reportando alta atividade. Ela puxou os dados de throughput dos oito sprints anteriores e descobriu que um squad concluía em média 12 itens por sprint enquanto o outro concluía 28, apesar de tamanhos e metas de sprint semelhantes. O squad com desempenho inferior tinha um padrão: os itens eram abertos, trabalhados e depois ficavam parados em review por três a cinco dias antes de fechar. O gargalo não era capacidade. Era latência de review.
Ela reestruturou o daily standup do squad para incluir uma verificação da fila de review e definiu uma norma do time: nenhum player deveria abrir um novo trabalho enquanto tivesse uma solicitação de review ativa. Em dois sprints, o throughput daquele squad subiu para 22 itens. Ela acompanhou a mudança usando o issue cycle time junto com o throughput para confirmar que os itens não estavam apenas sendo concluídos mais rápido, mas também passando menos tempo em estados de espera. Os dados revelaram o padrão. Ela decidiu o que mudar.
Como melhorar a métrica de throughput
- Dimensione os tickets antes do sprint começar. Tickets grandes e vagos inflam o work-in-progress e reduzem o throughput. Audite seus últimos três sprints: qualquer ticket que levou mais de quatro dias para fechar é candidato a decomposição. Itens menores e bem definidos avançam mais rápido e dão um sinal de throughput mais preciso.
- Reduza o tempo de espera em review como indicador antecipado. O PR cycle time é um dos indicadores antecipados mais fortes de throughput. Quando pull requests ficam sem review por mais de 24 horas, os itens se acumulam em progresso e o throughput cai. Defina uma norma do squad para o tempo de resposta no primeiro review e monitore semanalmente.
- Limite o WIP por player. Quando players têm três ou mais tickets ativos ao mesmo tempo, a troca de contexto destrói as taxas de conclusão. Limite o WIP a dois itens por player e observe como o throughput se estabiliza. O activity heatmap do DevStats mostra onde o trabalho está concentrado ou distribuído de forma irregular pelo squad.
- Audite a precisão do seu planejamento de sprint. O excesso crônico de compromissos suprime os scores de throughput artificialmente. Use os dados de planning accuracy para calibrar quanto trabalho o seu squad consegue concluir de forma realista em um sprint e comprometa-se com esse número em vez de um aspiracional.
- Separe o trabalho de interrupção do trabalho planejado. Solicitações não planejadas, escalações de bugs e reuniões ad hoc consomem capacidade sem aparecer nas contagens de throughput. Rastreie quanto do tempo do seu squad vai para trabalho não planejado em cada sprint e crie uma alocação de buffer para isso, em vez de deixar que ele corroa silenciosamente o throughput planejado.
Métrica de throughput vs. velocity
Throughput e velocity são frequentemente usados como sinônimos, mas medem coisas diferentes e têm perfis de confiabilidade distintos. Throughput conta itens concluídos de forma objetiva. Velocity soma story points, que são estimativas específicas de cada time e variam de significado entre squads e ao longo do tempo.
| Métrica de throughput | Velocity | |
|---|---|---|
| Mede | Contagem de itens de trabalho concluídos | Soma de story points concluídos |
| Começa quando | O item de trabalho é aberto | O sprint começa |
| Termina quando | O item de trabalho é fechado ou mergeado | O sprint termina |
| Melhor para | Comparação entre times, planejamento de capacidade, análise de fluxo | Tendência interna de sprint a sprint dentro de um único time |
Use throughput quando precisar de um sinal objetivo e comparável entre squads ou ao longo do tempo. Use velocity quando o seu time tiver práticas de estimativa estáveis e consistentes e você estiver rastreando tendências internas de sprint. As duas métricas funcionam bem juntas quando nenhuma é usada isoladamente. Você pode explorar como os dados de sprint se conectam aos padrões de throughput no DevStats.