Team throughput

A maioria dos líderes de engenharia sabe dizer o quanto o squad está ocupado. Poucos conseguem dizer o quanto ele realmente entrega. Team throughput é o número de itens de trabalho que um squad conclui e entrega em um período determinado. Sem uma visão clara disso, os compromissos de sprint viram chute e os prazos de entrega perdem credibilidade. Quando o throughput é invisível, os gargalos se escondem dentro do processo e atrasos acumulados parecem semanas ruins isoladas. Esta página cobre a definição, como medir, o que é bom, como melhorar e como o DevStats traz esses dados das suas ferramentas atuais.

Key takeaways

• Team throughput mede quantos itens de trabalho um squad conclui e entrega dentro de um período definido, tornando-se um dos sinais mais claros da saúde do pipeline de entrega. Sem ele, líderes de engenharia estimam capacidade pela intuição, não por evidências. Isso leva a compromissos perdidos e perda de confiança dos stakeholders.
• A fórmula central é direta: Team Throughput = número de itens concluídos / período de tempo. Um squad saudável de cinco a oito engenheiros tipicamente conclui de oito a 15 issues por sprint, mas isso varia bastante pelo tamanho dos itens, complexidade do codebase e maturidade do time. Acompanhar a tendência ao longo do tempo importa mais do que qualquer ponto de dado isolado.
• O erro mais comum dos times é confundir throughput com velocity. Velocity mede story points, que são estimativas subjetivas. Throughput conta itens concluídos, que são fatos objetivos. Times que otimizam para story points frequentemente inflam estimativas com o tempo, mascarando uma queda real na entrega e dando à liderança uma falsa sensação de progresso.
• O DevStats rastreia o team throughput automaticamente conectando ao seu provedor Git e ao seu issue tracker, com benchmarks contra mais de 1.000 times de engenharia. A funcionalidade de throughput mostra itens de trabalho concluídos ao longo do tempo no nível do squad, para você identificar tendências sem montar uma planilha sequer. Inicie um trial gratuito e veja seus números em menos de dois minutos.

Definição de team throughput

Team throughput é a contagem de itens de trabalho que um squad conclui e faz deploy dentro de uma janela de tempo definida, tipicamente um sprint ou uma semana do calendário. É uma métrica objetiva, baseada em contagem: um item foi entregue ou não foi. Sem estimativas, sem ponderação por complexidade.

Tecnicamente, a expressão é: Team Throughput = itens concluídos / período de tempo. As fontes de dados são o seu issue tracker (para tickets concluídos) e o seu provedor Git (para pull requests mergeados e deploys). Quando o throughput é combinado com o issue cycle time, você tem uma visão completa de quanto o squad entrega e quanto tempo cada item leva para chegar lá. Throughput consistente é um dos indicadores antecedentes mais fortes de entrega previsível, o que afeta diretamente a confiança no roadmap de produto e as decisões de investimento em engenharia.

Por que o team throughput importa para times de engenharia

Squads que não rastreiam throughput geralmente descobrem um problema só quando um prazo escorrega. A essa altura, o sinal já está presente há semanas: uma queda gradual em itens concluídos, um backlog crescente de trabalho em andamento e players fazendo context-switching em muitas frentes paralelas. Sem uma baseline de throughput, não há como distinguir um squad genuinamente sobrecarregado de um bloqueado por ineficiências de processo, como ciclos lentos de code review ou critérios de aceitação pouco claros.

Para líderes de engenharia, throughput se conecta diretamente aos KPIs que importam no nível do negócio: entrega no prazo, conclusão previsível de sprint e a capacidade de fazer compromissos críveis de roadmap para stakeholders de produto e executivos. Um squad com throughput estável consegue prever sua própria capacidade. Um squad com throughput errático não consegue, e essa incerteza se acumula em cada ciclo de planejamento. Você pode ver como o throughput se posiciona junto a outros sinais de entrega na funcionalidade de DORA metrics do DevStats, que mapeia a performance do seu squad nas quatro dimensões-chave de entrega de software.

Dentro do SPACE framework, throughput se encaixa na dimensão de Performance: mede resultados, não atividade. Medir é o primeiro passo. O que você faz com os dados é onde entra o seu julgamento como líder de engenharia.

Como medir team throughput

Conte o número de itens de trabalho que o seu squad move para o estado "concluído" dentro de um período definido. As janelas mais comuns são por sprint (uma ou duas semanas) e por período de sete dias corridos. Os dados vêm do seu issue tracker: Jira, Linear, GitHub Issues ou similar. Para squads que trabalham principalmente em pull requests, PRs mergeados são um proxy válido, mas o rastreamento no nível de issue dá um sinal mais granular sobre entrega de funcionalidades versus trabalho de manutenção.

Nenhum benchmark publicado cobre todos os tipos de time, já que o throughput varia pelo tamanho do squad, granularidade dos itens e modelo de release. A tabela abaixo descreve níveis qualitativos de performance com base em padrões observados em times de engenharia. A funcionalidade de benchmarks do DevStats permite comparar o throughput do seu squad com times de tamanho e estágio similares.

Esses intervalos assumem um tamanho de item razoavelmente consistente. Se o seu squad mistura grandes épicos com correções de bug de uma hora na mesma contagem, normalize por tipo de item antes de tirar conclusões. Acompanhar as linhas de tendência de throughput ao longo de oito a 12 semanas é mais informativo do que comparar um sprint com outro de forma isolada.

Team throughput na prática: um exemplo real

Uma VP de Engenharia em uma empresa SaaS de 40 pessoas percebeu que o squad de plataforma dela perdia consistentemente as metas de sprint, mesmo com os players reportando que estavam totalmente ocupados. Ela puxou os dados de throughput dos oito sprints anteriores e descobriu que os itens concluídos haviam caído de uma média de 12 por sprint para seis, enquanto o número de itens iniciados a cada sprint havia, na verdade, aumentado. Os dados apontaram para um problema de work-in-progress: muitos itens eram iniciados e deixados em revisão ou bloqueados, nunca chegando ao estado de concluído.

Ela definiu um limite de WIP no nível do squad de três itens ativos por player a qualquer momento e mudou as retros de sprint para focar em itens presos em revisão, em vez de itens ainda não iniciados. Também reduziu o tamanho médio dos itens dividindo tickets maiores em sub-tarefas entregáveis. Nos seis sprints seguintes, os itens concluídos voltaram a 11 por sprint e a previsibilidade do sprint, medida pela proporção de itens comprometidos em relação aos concluídos, melhorou significativamente. Os dados disseram onde procurar. A intervenção foi dela para desenhar e executar.

Como melhorar o team throughput

1. Reduza o work in progress. Defina um limite explícito de WIP por player, tipicamente dois a três itens ativos ao mesmo tempo. WIP alto cria overhead de context-switching que mata as taxas de conclusão. Observe os seus dados de sprint para itens que ficam em "em andamento" por mais de dois dias sem avançar.
2. Calibre o tamanho dos seus tickets. Itens que levam mais de três dias para concluir são grandes demais. Divida-os em sub-tarefas entregáveis. Itens menores e bem definidos avançam pelo pipeline mais rápido e dão um sinal de throughput mais preciso por sprint.
3. Reduza o tempo de espera em revisão. Code review lento é um dos killers de throughput mais comuns. Defina uma norma do squad para o tempo de resposta da primeira revisão, idealmente abaixo de quatro horas. A funcionalidade de PR cycle time do DevStats mostra onde os PRs ficam parados por mais tempo, para você identificar o padrão antes que vire hábito.
4. Audite a alocação antes de adicionar capacidade. Antes de assumir que o squad precisa de mais players, verifique como a capacidade existente está distribuída. Se uma parcela significativa do tempo vai para trabalho não planejado, incidentes ou solicitações entre times, o throughput do trabalho planejado vai sofrer independentemente do headcount. A funcionalidade de allocation no DevStats mostra como o esforço do squad está distribuído entre tipos de trabalho.
5. Estabilize o escopo do sprint após o kickoff. Adições no meio do sprint são uma das formas mais rápidas de derrubar o throughput. Defina um corte rígido para mudanças de escopo após o primeiro dia do sprint e meça com que frequência ele é respeitado. Melhorar a planning accuracy é um indicador antecedente direto da consistência do throughput.

Team throughput vs. velocity

Team throughput e velocity são ambas métricas de entrega no nível do sprint, mas medem coisas fundamentalmente diferentes: throughput conta itens concluídos como fatos objetivos, enquanto velocity conta story points, que são estimativas subjetivas que se desviam com o tempo.

Use throughput quando quiser uma visão imparcial do output de entrega ao longo do tempo. Use velocity quando o seu squad tiver estimativas de story points estáveis e bem calibradas e você estiver planejando capacidade para o próximo sprint dentro do mesmo contexto de time.