Organização de backlog: como manter vivo o artefato que guia o produto

Todo backlog começa organizado. Ele tem dez itens, todos escritos pela mesma pessoa, na mesma semana, com o mesmo problema em mente. Um ano depois, são trezentos itens, escritos por quinze pessoas diferentes, e ninguém consegue explicar por que metade deles está ali.

O que aconteceu no meio não foi desleixo. Foi a soma de decisões individuais, como uma ideia de reunião que virou card. O problema é que adicionar é barato e remover é caro.

O problema não é o backlog crescer. É ele crescer sem ninguém cuidar do que continua fazendo sentido.

O que o backlog é e o que ele não é

Vale começar pela definição formal, porque boa parte da confusão nasce dela. No Scrum Guide de 2020, o Product Backlog é a lista ordenada e emergente do que é necessário para melhorar o produto, e é a única fonte de trabalho assumida pelo time. Ele carrega um compromisso: o Product Goal, que descreve o estado futuro do produto e serve de alvo para o planejamento.

Duas consequências práticas costumam passar despercebidas.

A primeira: o backlog não é um repositório de pedidos. Se qualquer pessoa consegue criar um item sem passar por uma decisão, o artefato já perdeu a função.

A segunda: o backlog não é o registro de tudo que já foi pedido. Itens existem para serem realizados ou descartados, não para ficarem guardados como prova de que alguém pediu. Registro de pedido é outra coisa, e merece outro lugar.

Oito sinais de que o backlog adoeceu

Saúde de backlog é observável. Estes são os sintomas que aparecem antes de o time perceber o problema:

• Itens parados há meses. Nenhuma revisão desde que entraram. Se um item sobreviveu a três trimestres sem ser tocado, ele não está esperando: ele foi esquecido.

• Tarefas grandes demais. Itens que ninguém consegue estimar, entender por inteiro ou entregar dentro de um ciclo.

• Itens duplicados. Antes de criar o item é importante verificar se ele já foi cadastrado em outro momento.

• Entra mais do que sai. Nenhum corte, só acúmulo.

• Prioriza quem grita mais alto. A ordem muda por pressão política, não por critério explícito.

• Ninguém explica por que o item está ali. O card perdeu o problema que o originou.

• Empurrar dívida técnica indefinidamente. Combine uma cota fixa com o time: a cada dez itens da sprint, dois são de dívida técnica. Reservar a capacidade antes de priorizar evita a negociação item a item.

• Usar IA para escrever mais. Ferramentas de IA são ótimas para redigir histórias, critérios de aceite, cenários de teste, decomposição, desde que utilizadas da melhor forma. A IA propõe, mas só quem entende o contexto do cliente é você.

O que caracteriza um backlog bem organizado

Existem dois acrônimos que sobreviveram ao tempo e continuam úteis. Eles operam em níveis diferentes: um avalia a lista, o outro avalia o item.

DEEP: a qualidade da lista

Cunhado por Roman Pichler e Mike Cohn, o DEEP descreve as quatro características de um bom backlog de produto. Pichler é direto sobre o problema que o acrônimo tenta resolver: na prática, backlogs costumam ser longos demais, detalhados demais e, por isso, difíceis de usar.

CRITÉRIO	O QUE SIGNIFICA
Detailed appropriately	Detalhado na medida certa. Itens do topo são descritos com mais detalhe que os da base, e não o contrário.
Emergent	Emergente. O backlog muda conforme novas informações chegam; ele não é um plano congelado.
Estimated	Estimado. Existe uma noção do esforço, mais precisa no topo e grosseira na base.
Prioritized	Priorizado. Os itens têm ordem, não apenas rótulos de prioridade.

Um alerta de Pichler que vale reter: backlog detalhado demais costuma andar junto com backlog engessado. Quanto mais cedo você congela o detalhe, mais cara fica a mudança de ideia depois.

INVEST: a qualidade do item

Criado por Bill Wake em 2003 no artigo INVEST in Good Stories, and SMART Tasks, e popularizado por Mike Cohn em User Stories Applied no ano seguinte, o INVEST é um checklist para avaliar uma história: Independent, Negotiable, Valuable, Estimable, Small, Testable.

Há uma leitura equivocada muito comum aqui, tratar o INVEST como porteiro, um teste que a história precisa passar antes de entrar na sprint. Como observa Maarten Dalmijn, o checklist foi pensado para ser usado enquanto se trabalha na história, não apenas antes de pegá-la. A letra mais ignorada é o N: uma história é uma descrição curta de uma necessidade, não um contrato fechado de funcionalidades.

Refinamento é rotina, não cerimônia

O Scrum Guide 2020 define refinamento como o ato de quebrar e detalhar itens do backlog em itens menores e mais precisos, e descreve isso como uma atividade contínua ao longo da Sprint. A versão de 2017 era mais prescritiva e falava em adicionar detalhe, estimativas e ordem; na revisão de 2020 a palavra “estimate” saiu inteiramente do guia.

Também saiu a recomendação de reservar até 10% da capacidade do time para refinamento. Ela continua sendo uma regra prática razoável, e dependerá muito do contexto de cada time.

O critério que o guia mantém é objetivo e útil: itens que o time consegue concluir dentro de uma Sprint são considerados prontos para seleção no planejamento. É isso que “refinado” significa na prática. A Scrum Alliance sugere manter entre 1,5 e 2 sprints de trabalho pronto à frente, calculado pela velocidade do time. O suficiente para não travar.

Reunião ou assíncrono?

Depende. Quando o refinamento é feito em conjunto, a decisão é coletiva e o conhecimento se espalha. Quando é assíncrono, ganha-se flexibilidade. Nenhum dos dois é mais correto.

O que não é opcional é o resultado: o item da próxima sprint precisa estar pronto antes dela começar. Se o refinamento só começa no planejamento, temos um sintoma, não a solução.

Hierarquia e nível de detalhe

A estrutura em camadas — épico, feature, história, tarefa — existe para resolver um problema específico: permitir que o backlog tenha granularidades diferentes ao mesmo tempo.

NÍVEL	O QUE É	QUANDO DETALHAR
Épico	Grande iniciativa ligada a um objetivo estratégico	Quando entrar no horizonte do trimestre
Feature	Funcionalidade específica que compõe o épico	Quando entrar no horizonte da release
User Story	Menor unidade de valor entregável ao usuário	Antes do planejamento da sprint
Task	Trabalho técnico para implementar a story	No planejamento, com o time

O teste mais rápido para saber se um item está no nível errado: peça para duas pessoas do time classificarem o mesmo card. Quando metade diz “feature” e metade diz “épico”, o item é grande demais.

Arquivar também é decisão de produto

Aqui está a raiz da causa. Joca Torres descreve com precisão o mecanismo: quando o gestor de produtos percebe que a resposta “vou colocar no backlog” acalma quem está pedindo, ele passa a usar essa resposta de forma indiscriminada. O backlog vira depósito de conversas.

O antídoto não é um framework. É aceitar que dizer “não” faz parte do trabalho, e que o “não” precisa de justificativa, não de desculpa.

Melissa Perri deu nome ao efeito agregado disso em Escaping the Build Trap: organizações que medem sucesso por quantidade de coisas entregues acabam produzindo funcionalidades para cumprir cronograma em vez de resolver problema de cliente. Um backlog que só cresce é o sintoma mais visível dessa armadilha.

Na prática, arquivar fica mais fácil quando o “não” vira registro. Documente a decisão com o motivo e um gatilho objetivo de reabertura. O assunto para de voltar a cada trimestre, e o arquivamento deixa de parecer arbitrário.

Um ritual simples de manutenção

Saúde de backlog não vem de mutirão. Vem de cadência. Uma rotina mínima que funciona na maioria dos times:

CADÊNCIA	RITUAL	O QUE ACONTECE
Semanal	Refinamento	Itens da próxima sprint claros e prontos antes dela começar
Mensal	Limpeza	Revisar o que está parado há mais de 90 dias: manter, quebrar ou arquivar
Trimestral	Repriorização	Rever a ordem do backlog contra os objetivos atuais do produto

Na limpeza mensal, a regra que faz diferença é estabelecer uma cota mínima de arquivamento. Sem cota, todo mundo mantém tudo, e a reunião vira só mais uma reunião.

O que levar daqui

Crescer é normal. Crescer sem curadoria é o problema. É natural que o backlog aumente a cada ciclo de feedback com usuários e stakeholders. O que não pode é ninguém revisitar o que já está lá.

Refinamento é rotina, não cerimônia. Reunião semanal ajuda, mas o trabalho acontece continuamente durante a sprint.

Backlog saudável é menor. Se ao final de um trimestre a lista está do mesmo tamanho, faltou organização, e, principalmente, faltou decisão.

Referências em inglês

AGILE ALLIANCE. INVEST: Agile Glossary. [S. l.], [s. d.]. Disponível em: https://agilealliance.org/glossary/invest . Acesso em: 11 nov. 2026.

COHN, M. User Stories Applied: For Agile Software Development. Boston: Addison-Wesley, 2004.

DALMIJN, M. Revisiting INVEST 20+ Years Later. [S. l.], [s. d.]. Disponível em: https://mdalmijn.com/p/revisiting-invest-20-years-later . Acesso em: 11 nov. 2026.

JOCHAM, R.; COLEMAN, J.; SUTHERLAND, J. Scrum Guide Expansion Pack. Versão 2025.6. [S. l.], 2025. Disponível em: https://scrumexpansion.org/scrum-guide-expanded/2025.6 . Acesso em: 11 nov. 2026.

PERRI, M. Escaping the Build Trap: How Effective Product Management Creates Real Value. Sebastopol: O’Reilly Media, 2018.

PICHLER, R. Agile Product Management with Scrum: Creating Products that Customers Love. Boston: Addison-Wesley, 2010.

PICHLER, R. Make the Product Backlog DEEP. Roman Pichler, [s. d.]. Disponível em: https://www.romanpichler.com/blog/make-the-product-backlog-deep . Acesso em: 11 nov. 2026.

PICHLER, R. Product Backlog FAQs. Roman Pichler, [s. d.]. Disponível em: https://www.romanpichler.com/blog/product-backlog-faqs . Acesso em: 11 nov. 2026.

RUBIN, K. S. Essential Scrum: A Practical Guide to the Most Popular Agile Process. Upper Saddle River: Addison-Wesley, 2012.

SCHWABER, K.; SUTHERLAND, J. The Scrum Guide. Nov. 2020. Disponível em: https://scrumguides.org/scrum-guide.html . Acesso em: 11 nov. 2026.

SCRUM ALLIANCE. The Keys to Effective Product Backlog Refinement. [S. l.], [s. d.]. Disponível em: https://resources.scrumalliance.org/Article/keys-effective-product-backlog-refinement . Acesso em: 11 nov. 2026.

WAKE, B. INVEST in Good Stories, and SMART Tasks. XP123, 2003. Disponível em: https://xp123.com/articles/invest-in-good-stories-and-smart-tasks . Acesso em: 11 nov. 2026.

WOLPERS, S. Product Backlog Refinement: How to Succeed as a Scrum Team. Scrum.org, [s. d.]. Disponível em: https://www.scrum.org/resources/blog/product-backlog-refinement-how-succeed-scrum-team . Acesso em: 11 nov. 2026.

Referências em português

CWI SOFTWARE. Scrum Guide Expansion Pack (2025): a evolução do Scrum além da essência. [S. l.], 2025. Disponível em: https://cwi.com.br/blog/scrum-guide-expansion-pack-2025 . Acesso em: 11 nov. 2026.

K21 BRASIL. Scrum Guide Expansion Pack 2025: entenda as mudanças e teorias. [S. l.], 2025. Disponível em: https://br.k21.global . Acesso em: 11 nov. 2026.

PM3. Product backlog: o que é e como priorizar tarefas em Produto. [S. l.], [s. d.]. Disponível em: https://pm3.com.br/blog/product-backlog-como-priorizar-tarefas . Acesso em: 11 nov. 2026.

SCHWABER, K.; SUTHERLAND, J. Guia do Scrum: o guia definitivo para o Scrum: as regras do jogo. Nov. 2020. Disponível em: https://scrumguides.org . Acesso em: 11 nov. 2026.

SCRUM PORTUGAL. O que mudou com o novo Scrum Guide 2020. [S. l.], [s. d.]. Disponível em: https://scrumportugal.pt/scrum-guide . Acesso em: 11 nov. 2026.

TORRES, J. Crescimento: como priorizar o roadmap? Medium, [s. d.]. Disponível em: https://jocatorres.medium.com . Acesso em: 11 nov. 2026.

TORRES, J. Gestão de Produtos: como aumentar as chances de sucesso do seu software. São Paulo: Casa do Código, [s. d.].

TORRES, J. Mais sobre priorização de roadmaps. Medium: Gestão de Produtos, [s. d.]. Disponível em: https://medium.com/gestao-produtos . Acesso em: 11 nov. 2026.

—

Nota sobre as fontes: o Scrum Guide oficial continua sendo a edição de 2020. O Expansion Pack de 2025 é uma iniciativa independente de Ralph Jocham, John Coleman e Jeff Sutherland, publicada como complemento útil como leitura, mas não como referência normativa.