Por que o backlog nunca diminui e como destravar a velocidade de entrega do seu time

Você olha para o backlog do seu time e sente um incômodo familiar: ele nunca diminui. Para cada entrega feita, duas novas tarefas aparecem. O time trabalha, os sprints passam, as reuniões acontecem — e mesmo assim a sensação é de estar correndo numa esteira. Esse cenário não é uma questão de esforço. É uma questão de sistema.

Em mais de 20 anos assessorando empresas de tecnologia — de fintechs como BTG e XP a plataformas como Livelo e MaxMilhas — vi esse padrão se repetir em organizações de todos os tamanhos. O problema raramente está na competência individual dos desenvolvedores. Está na forma como o trabalho é organizado, priorizado e desbloqueado. E a boa notícia é que isso tem solução estrutural.

O backlog não é o problema. É o sintoma.

A primeira armadilha é tratar o backlog de produto como inimigo a ser vencido. Ele não é. Um backlog nunca vai zerar — e não deveria. O problema real é quando o backlog cresce mais rápido do que o time consegue entregar, criando uma dívida de demanda que paralisa decisões e desmotiva equipes.

Existe um conceito pouco usado fora de ambientes de engenharia de alta performance: a relação entre taxa de entrada e throughput de engenharia. Se o seu time entrega 20 itens por mês e recebem 35 solicitações novas no mesmo período, o backlog cresce 15 itens por ciclo. Em seis meses, você tem 90 itens acumulados que nunca existiram antes. Em um ano, a situação está fora de controle.

Segundo dados do relatório DORA (DevOps Research and Assessment) de 2023, times de alto desempenho entregam código em produção múltiplas vezes por dia, com taxa de falha menor que 5%. Times de baixo desempenho levam entre um mês e seis meses para uma única entrega significativa. Essa diferença não é de talento — é de processo, arquitetura e gestão.

Por que o throughput trava: os cinco bloqueadores reais

Quando analiso a velocidade de entrega de um time pela primeira vez, mapeio sistematicamente os pontos de atrito. Na maioria dos casos, os bloqueadores se concentram em cinco categorias:

• Dependências não gerenciadas: Tarefas que parecem independentes mas precisam de outro time, sistema ou aprovação para avançar. Quando ninguém mapeia essas dependências antecipadamente, o item para no meio do sprint sem que ninguém saiba exatamente por quê.
• Trabalho não planejado excessivo: Bugs críticos, pedidos urgentes do CEO, incidentes de produção — esses itens consomem, em média, 30 a 40% da capacidade real dos times que não têm um processo para absorvê-los sem destruir o planejamento.
• Refinamento insuficiente: Histórias mal escritas chegam ao desenvolvimento com ambiguidades que geram retrabalho. Um estudo da McKinsey aponta que até 25% do tempo de engenharia em empresas de médio porte é perdido em retrabalho por falta de clareza nos requisitos.
• Revisão de código como gargalo: Em muitas organizações brasileiras que acompanhei, pull requests ficam abertos por três, quatro, às vezes sete dias sem revisão. O desenvolvedor segue para outra tarefa, perde contexto, e quando volta para ajustar, o custo cognitivo triplicou.
• Ambientes instáveis: Pipelines quebrados, ambientes de homologação que não refletem produção, deploys manuais — cada um desses elementos adiciona fricção invisível que se acumula em horas perdidas toda semana.

O que é curioso é que a maioria dos líderes que converso sabe que esses problemas existem. O que falta é prioridade para resolvê-los, porque a pressão por novas features sempre parece mais urgente do que corrigir o sistema que as produz.

A falácia da capacidade: por que contratar mais não resolve

A resposta instintiva de muitos CTOs e fundadores quando o backlog cresce é contratar mais desenvolvedores. É uma decisão compreensível, mas frequentemente equivocada — pelo menos como primeira medida.

Fred Brooks descreveu isso nos anos 1970 no clássico The Mythical Man-Month: adicionar pessoas a um projeto atrasado o atrasa ainda mais, pelo menos no curto prazo. A razão é que novos membros precisam de onboarding, consomem tempo dos sêniores, e aumentam a complexidade de comunicação exponencialmente.

Na prática, já vi isso acontecer em uma fintech nacional de médio porte: o time de engenharia dobrou em 18 meses — de 40 para 80 pessoas — e a velocidade de entrega caiu 15%. O motivo? A estrutura de times, processos e arquitetura não foram adaptados para suportar a escala. Mais pessoas entraram num sistema disfuncional e o tornaram mais disfuncional.

Isso não significa que contratar seja errado. Significa que contratar sem antes destravrar os bloqueadores sistêmicos é jogar dinheiro num problema estrutural. O retorno real vem quando você aumenta o throughput por pessoa, não apenas o número de pessoas.

Como destravar a velocidade de entrega na prática

Destravar a produtividade do time dev exige uma abordagem em três frentes simultâneas: visibilidade, fluxo e cultura. Aqui estão as alavancas que consistentemente geram resultado:

1. Meça o que importa, não o que é fácil de medir. A maioria dos times mede story points ou velocity de sprint — métricas que dizem pouco sobre impacto real. Comece a medir lead time (tempo do item entrar no backlog até ir para produção) e cycle time (tempo do início do desenvolvimento até a entrega). Esses números revelam onde o trabalho para de fato.

2. Implemente WIP limits (Work in Progress). Limitar o número de itens em andamento simultaneamente parece contraintuitivo, mas é uma das alavancas mais poderosas de gestão de times de tecnologia. Times que trabalham em muitas coisas ao mesmo tempo terminam poucas. Definir um limite de WIP por estágio do kanban força o time a terminar antes de começar — e isso, sozinho, pode reduzir o lead time em 40 a 60% em oito semanas.

3. Reserve capacidade explícita para trabalho não planejado. Se o seu time não tem um buffer formal para incidentes e urgências, esse trabalho vai invadir o planejado de qualquer forma — só que de forma caótica. Alocar 20 a 30% da capacidade para absorver imprevistos não é desperdício. É engenharia de resiliência aplicada ao processo.

4. Reduza o tamanho dos itens de trabalho. Itens grandes são inimigos do fluxo. Uma feature que leva três semanas para ser entregue é uma feature que não gera feedback por três semanas, que bloqueia a branch por três semanas, e que, se estiver errada, vai gerar retrabalho de três semanas. Aprenda a fatiar histórias em entregas menores e independentes. Times maduros entregam itens que levam de um a três dias, não semanas.

5. Crie um processo explícito de refinamento. Antes do item entrar no sprint, ele deve estar claro o suficiente para que qualquer pessoa do time consiga desenvolvê-lo sem depender de clarificações constantes. Invista tempo de qualidade na definição de critérios de aceite, mapeamento de dependências e estimativa de esforço. Cada hora investida em refinamento economiza quatro horas de retrabalho — é uma das relações de custo-benefício mais claras que existe em engenharia de software.

6. Trate a revisão de código como atividade crítica, não opcional. Defina SLAs internos para revisão de PRs — por exemplo, toda revisão deve ser feita em no máximo 24 horas. Isso exige mudança cultural, mas o impacto no cycle time é imediato. Uma das práticas que mais recomendo é o code review office hour: um slot fixo no dia onde revisões são priorizadas coletivamente.

O papel da liderança: desbloqueador ou gargalo?

Existe uma dimensão da velocidade de entrega que nenhuma ferramenta ou processo resolve sozinho: o comportamento da liderança. Em muitas organizações, o CTO ou o VP de Engenharia — com as melhores intenções — se torna o maior gargalo do time.

Isso acontece quando decisões técnicas relevantes precisam de aprovação do líder. Quando o time não tem autonomia para escolher abordagens dentro de um espaço seguro de decisão. Quando cada mudança arquitetural exige uma reunião com o gestor. Esse padrão de centralização é compreensível em times pequenos, mas é letal em times que crescem.

Times de alto desempenho não são aqueles que têm o líder mais inteligente. São aqueles onde o líder cria as condições para que as pessoas tomem boas decisões sem depender dele o tempo todo.

A prática mais eficaz que vi funcionar é a criação explícita de domínios de decisão autônoma: um mapa claro de quais decisões o time pode tomar sozinho, quais precisam de alinhamento, e quais exigem aprovação. Isso remove ambiguidade, acelera o fluxo e desenvolve a maturidade do time ao longo do tempo.

O que esperar quando você começa a corrigir o sistema

Uma advertência honesta: quando você começa a aplicar essas mudanças, o primeiro efeito visível pode ser uma queda temporária na velocidade percebida. Isso é normal. O time está aprendendo novos comportamentos, questionando hábitos antigos, e ainda carregando a dívida técnica e organizacional acumulada.

Em geral, os primeiros resultados mensuráveis aparecem entre quatro e oito semanas. Redução de lead time, menos retrabalho, sprints mais previsíveis. Em três a seis meses, times que implementam essas mudanças de forma consistente costumam apresentar aumento de 40 a 80% na velocidade de entrega real — não em story points, mas em features funcionando em produção.

Mais importante do que os números: o time começa a trabalhar com menos ansiedade, mais foco e maior senso de progresso. Isso tem impacto direto na retenção de talentos — que, no mercado brasileiro de tecnologia em 2024, onde a escassez de profissionais sêniores é crítica, vale tanto quanto qualquer aumento de produtividade.

A pergunta que você deveria estar fazendo

Antes de encerrar, quero deixar uma reflexão prática. A maioria dos líderes de tecnologia que me procura está fazendo a pergunta errada. A pergunta costuma ser: "Como faço meu time entregar mais rápido?" A pergunta certa é: "O que está impedindo meu time de entregar no ritmo que ele é capaz?"

São perguntas diferentes. A primeira pressupõe que o problema é esforço. A segunda pressupõe que o problema é sistema. E sistemas têm pontos de alavanca — lugares onde uma mudança pequena gera impacto desproporcional.

O backlog de produto que nunca diminui não é uma fatalidade do trabalho em tecnologia. É um sinal de que o sistema de trabalho precisa ser redesenhado. E isso, diferente de contratar dez engenheiros sêniores, está inteiramente dentro do controle de quem lidera o time.

Se você chegou até aqui, é porque esse problema é real para você. Talvez esteja diante de um backlog crescente, de um time que trabalha muito mas entrega pouco, ou de uma pressão de negócio que o sistema atual simplesmente não consegue absorver. Esses são os cenários onde atuo — e onde uma perspectiva externa, com método e experiência acumulada em dezenas de organizações, pode fazer a diferença entre mais um trimestre de promessas não cumpridas e uma virada real de desempenho. Entre em contato e vamos conversar sobre o que está travando a entrega do seu time.