Seu backlog é 90% dívida técnica disfarçada de feature.

A cena se repete em sala de produto brasileira com fidelidade operacional. Product manager entra na planning com uma lista de 47 itens no backlog. Destes, 30 estão rotulados como “melhoria”, “otimização”, “refatoração”. Nenhum dos 30 tem valor claro declarado para o usuário final. Nenhum dos 30 tem métrica de impacto anexada. Nenhum dos 30 tem prazo de validade. Entram no sprint porque o time precisa de “trabalho técnico” entre uma feature e outra, e a justificativa recorrente é que “é necessário” — sem que “necessário” esteja definido em termos de quem paga o custo do atraso. A sprint roda. Os 17 itens com valor de usuário declarado são empurrados para a sprint seguinte. O backlog cresce. O próximo planning repete o movimento. Três quarters depois, o backlog tem 200 itens, o time entrega menos do que entregava antes, e ninguém consegue identificar o momento em que a coisa degringolou.

A afirmação que sustenta a operação — “dívida técnica é responsabilidade do time de engenharia, e o time precisa de tempo para pagá-la” — é tecnicamente correta e operacionalmente falsa. A dívida não se acumula porque o time não tem tempo. Se acumula porque ninguém definiu o critério que decide o que entra no sprint e o que fica no backlog. A consequência é que o backlog vira arquivo morto de ideias, e a única força que governa o que sai do arquivo é a senioridade política de quem propôs o item. A dívida técnica deixou de ser problema técnico e virou problema de governança de produto. O custo do atraso está sendo pago por quem não foi consultado sobre a decisão de atrasar.

O que o backlog de 47 itens realmente diz

A primeira pergunta que o número provoca é: por que 47? O backlog não é registro de demanda acumulada de mercado. É registro do que a organização decidiu não decidir. Cada item que entra no backlog sem prazo, sem critério de saída e sem métrica de impacto é uma decisão de postergamento que alguém fez em algum momento, e a soma das postergações é o que o time chama de “trabalho a fazer”. A força que governa o crescimento do backlog é a mesma que governa o crescimento de qualquer sistema sem critério de entrada: a Lei de Parkinson documentada por Cyril Northcote Parkinson em 1955 — “o trabalho se expande até preencher o tempo disponível para completá-lo”. A unidade de medida no backlog não é valor de usuário. É atenção de quem tem tempo para escrever um card.

A operação real do backlog na maioria dos times produz três saídas que se parecem com priorização, mas não são. A primeira é inflação por categoria-coringa: a categoria “melhoria” absorve qualquer item que não tem valor de usuário claro, sem que a categoria force o autor do card a declarar o impacto. A segunda é inflação por senioridade política: itens propostos por quem tem mais voz na mesa entram com peso maior que itens propostos por quem tem menos, independentemente do valor. A terceira é inflação por deferência histórica: itens que já estão no backlog há mais de um ano são tratados como “claramente importantes, porque ainda estão aqui”, quando a permanência no backlog por anos é evidência de que ninguém conseguiu justificar tirá-los.

Em qualquer um dos três casos, o backlog vira arquivo de opinião, e a próxima planning começa com o time negociando entre 47 opiniões, em vez de executar 8 decisões alinhadas com impacto real. O custo do inchaço não é o tempo gasto lendo os 47 cards na planning. O custo é a diluição da atenção do time sobre os 8 itens que de fato importam. A regra de Gerry Weinberg em Secrets of Consulting aplica-se literalmente: “uma coisa que é tudo é nada”. Backlog de 47 itens é funcionalmente equivalente a backlog de zero itens do ponto de vista de execução.

Dívida técnica como decisão de postergamento

A fragilidade central do argumento “precisamos pagar dívida técnica” não é a dívida em si. É a ausência de contabilidade sobre o que está sendo pago. Ward Cunningham cunhou o termo “dívida técnica” em 1992, no relatório interno da WyCog. A definição original é literal, financeira, sem metáfora: você escolheu não fazer algo direito agora, e está pagando juros depois. O conceito foi criado para que times pudessem tomar a decisão de postergar conscientemente, sabendo o custo do adiamento. O uso que a indústria fez do termo, nas três décadas seguintes, inverteu a lógica: “dívida técnica” virou sinônimo de “trabalho de engenharia que PM não entende”, e a dívida saiu do orçamento de governança e entrou no orçamento de boa vontade técnica.

A inversão é o bug. Dívida técnica não é trabalho de engenharia. É decisão de negócio postergada. A decisão de não refatorar aquele módulo foi tomada por alguém com poder de produto, em algum momento, sob alguma justificativa de prazo. A dívida está onde a decisão foi tomada, não onde a refatoração vai acontecer. A implicação operacional é que o time de produto precisa de critério explícito para decidir o que entra no backlog como dívida, e o critério precisa de métrica anexada. A métrica que justifica a entrada é uma de três: (a) a velocidade do time cai X% por release enquanto a dívida não é paga, (b) a taxa de bugs sobe Y% por causa específica da dívida, ou (c) o retrabalho consome Z horas por sprint em consequência direta. Sem uma das três, o item não é dívida — é especulação sobre o futuro.

O DORA Report 2024 documenta que times de elite operam com backlogs curtos e rotatividade alta de itens. A métrica primária do DORA é deployment frequency e lead time for changes, e ambas correlacionam-se negativamente com tamanho do backlog. A correlação é causal, não estatística: backlog longo é preditor de baixa performance porque dilui atenção, infla planning, e desincentiva o time a questionar itens antigos. O DORA não recomenda limite numérico de itens, mas a evidência empírica em times de elite é consistente: backlogs operacionais menores que 15 itens, com itens prioritários de longa data explicitamente fora do operacional e em uma lista separada de “oportunidades futuras”. A divisão entre backlog ativo e backlog de oportunidades é o critério administrativo que materializa a tese de que nem tudo no backlog é trabalho.

O critério de entrada que substitui a intuição

A substituição da intuição por critério é a operação concreta que separa backlog de arquivo. O critério precisa de três propriedades para funcionar: ser declarável antes do item entrar no backlog, ser verificável em alguma métrica observável, e produzir resposta binária — o item entra ou não entra. Critérios vagos produzem inflação. Critérios verificáveis produzem decisão.

A primeira propriedade é declarabilidade pré-entrada. O autor do card precisa declarar a métrica de impacto antes de submeter o item. A declaração é texto simples: “este item custa 4 horas de retrabalho por sprint no módulo X”, ou “este item faz a velocidade do time cair 8% nas histórias que tocam Y”. A declaração fica anexada ao card e é revisada na planning. Itens sem declaração não entram na fila. A regra não é “justificar o item” — é “anexar métrica”. A diferença é semântica e operacional: “justificar” admite argumento político, “anexar métrica” só admite evidência.

A segunda propriedade é verificabilidade observável. A métrica declarada precisa ser algo que pode ser medido em produção ou em métricas de processo do time. Velocidade, bug rate, retrabalho, lead time, deploy frequency — todas são observáveis. “Importância estratégica” não é. “Refatoração para deixar o código mais limpo” não é. “Boa prática de engenharia” não é. A verificabilidade força a discussão a sair do domínio da opinião e entrar no domínio da evidência. O time que opera com critério verificável descobre, na primeira planning, que metade dos itens do backlog não tem métrica declarada — e essa descoberta é o objetivo do critério.

A terceira propriedade é resposta binária. O critério produz “entra” ou “não entra”, sem meio-termo. Itens que entram com métrica declarada e impacto mensurável vão para a fila operacional. Itens sem métrica declarada ou com impacto não-mensurável vão para uma lista separada — o “backlog de oportunidades” no sentido de Weinberg. A lista separada não desaparece. Existe para que o item possa ser promovido quando a métrica aparecer. A promoção é o que mantém a honestidade da lista: itens não saem do backlog de oportunidades por inércia, saem quando alguém consegue declarar o impacto. A lista de oportunidades tem data de validade por construção — o item sem impacto declarado por mais de 6 meses é candidato a deletar, não a fazer.

A reorganização que produziu 40% mais entrega

O caso que materializa o critério é anonimizado, e vem de um cliente com 47 itens no backlog operacional. O diagnóstico inicial seguiu o padrão da indústria: velocity em queda, retrospectiva identificando “muita dívida técnica” como causa, e PM defendendo que “o time precisa de tempo para pagar a dívida antes de continuar entregando features”. O diagnóstico estava parcialmente correto — velocity estava em queda — mas a causa raiz não era a dívida em si. A causa raiz era a ausência de critério de entrada, que produzia inflação por categoria-coringa, e a inflação diluía a atenção do time sobre os itens de valor real.

A operação de reclassificação foi direta. O primeiro passo foi pedir ao autor de cada um dos 47 cards que declarasse a métrica de impacto em uma frase: “este item reduz X, aumenta Y, ou elimina Z”. O resultado foi que 30 dos 47 cards não tinham métrica declarável. Os 30 itens foram movidos para a lista de oportunidades, com a regra explícita de que poderiam voltar ao backlog operacional se a métrica aparecesse. O segundo passo foi perguntar para os 17 restantes se a métrica declarada era a mais impactante, ou se havia dependência entre eles. Sete itens eram derivados de dois outros, e foram consolidados. O backlog operacional saiu de 47 para 8 itens.

Os dois primeiros sprints após a reclassificação entregaram os 8 itens em 6 semanas, com velocity 40% maior do que a média dos dois quarters anteriores. A explicação não é que o time ficou mais rápido. O time ficou mais focado. Os 8 itens representavam trabalho real, com critério declarado, e a planning parou de negociar entre 47 opiniões para executar 8 decisões. A percepção do time sobre a própria produtividade mudou retroativamente: o que era interpretado como “dívida técnica que atrasa tudo” era, na verdade, “arquivo de ideias que dilui a atenção sobre o trabalho real”. A dívida acumulada não havia desaparecido. Estava em uma lista separada, onde o time conseguia ignorar a inércia política e focar no que era executável.

O terceiro passo foi a parte politicamente difícil. Três dos 30 itens que foram para a lista de oportunidades tinham dono com senioridade política suficiente para pressionar pela execução. A pressão foi tratada com a pergunta direta: “qual a métrica de impacto?”. Os três itens não tinham métrica. Dois foram arquivados. Um retornou ao backlog quando o autor conseguiu declarar métrica observável. O processo de governança foi mantido mesmo sob pressão política, e o resultado foi que a senioridade deixou de ser critério suficiente para entrar no backlog. A regra é geral: senioridade política não substitui métrica de impacto declarada.

A provocação e a resposta

A frase que materializa a provocação do briefing é a que precisa aparecer no post sem amenização. “Se ninguém sente o impacto da feature não existir, ela não é feature. É masturbação técnica.” A frase é forte, e a força é intencional. A operação que a frase denuncia é real: times gastam horas em trabalho técnico que tem valor de authorship para quem o fez, e tem zero valor para quem usa o sistema. O termo “masturbação técnica” nomeia a operação sem eufemismo. A descrição alternativa — “trabalho técnico sem valor de usuário” — é semanticamente idêntica, mas o impacto é menor porque a descrição não obriga o leitor a confrontar o que está defendendo.

A resposta à provocação não é “pare de fazer”. A resposta é “faça com critério”. Refatoração é legítima quando tem impacto mensurável declarado: a query de banco que cai de 800ms para 40ms, o deploy que sai de 12 minutos para 3, o bug que para de aparecer em produção. Cada um desses itens tem métrica, e cada um deles paga o custo do retrabalho de quem refatorou. O que a provocação ataca é a refatoração que tem como critério “é a coisa certa a fazer”, sem que a coisa certa a fazer tenha métrica anexada. A diferença entre as duas é a mesma entre investimento e exercício de estilo — e o backlog, sem critério de entrada, não distingue uma da outra.

A resposta operacional da provocação é a regra de três do fechamento. Três coisas bem feitas superam dez coisas meio-feitas. O backlog de 47 itens que vira backlog de 8 produz 40% mais entrega porque o time está fazendo três coisas bem feitas por sprint, em vez de tentar fazer dez coisas que nenhuma das quais está terminada no fim do ciclo. A regra não é nova — Kent Beck cunhou o princípio de “fazer a coisa mais simples que funciona” em Extreme Programming Explained, e a intuição está no movimento NoEstimates de Woody Zuill. A novidade é a aplicação administrativa: a regra aplicada ao backlog como filtro de entrada, não como filosofia de execução. O filtro é o que materializa a regra.

O critério para a próxima planning

A próxima planning começa com a pergunta que importa. A pergunta não é “quanto tempo vai levar”. A pergunta é “alguém sente o impacto disto não existir”. Se sim, declare a métrica e entre no sprint. Se não, vá para a lista de oportunidades com data de validade de seis meses, e aguarde a métrica aparecer. O backlog operacional é para itens com impacto declarado. A lista de oportunidades é para itens com esperança de impacto. A diferença entre as duas listas é o que separa execução de arquivo.

O time que opera com essa separação descobre, na primeira planning, que o backlog operacional cabe em uma página. A planning sai de duas horas de discussão para vinte minutos de decisão. O tempo recuperado vai para o trabalho real, e o trabalho real é o que o time se propôs a entregar no início do projeto. O resto é ruído que estava esperando critério de entrada. Backlog de 47 itens é ruído esperando critério. Backlog de 8 itens é trabalho esperando execução. A escolha entre os dois é a decisão que o PM, com a estrutura de governança certa, precisa tomar antes da próxima planning — e a métrica de quem tomou a decisão certa aparece no quarter seguinte, na forma de 40% mais entrega.