Neste capítulo, você vai entender o Product Backlog como o Guia do Scrum o define e como mantê-lo vivo por meio do refinamento. É o artefato central do Product Owner: tudo o que o time constrói passa por ele, e sua qualidade determina a qualidade das Sprints.

O Product Backlog é uma lista emergente e ordenada do que é necessário para melhorar o produto. É a única fonte de trabalho do Scrum Team. Os itens do topo são menores, mais claros e prontos para serem selecionados em uma Sprint; os de baixo podem ser vagos, porque serão detalhados quando chegar a vez. Refinamento é a atividade contínua de quebrar, detalhar e ordenar os itens.

Emergente, não completo

A palavra que mais importa na definição é emergente. O backlog nunca está pronto, e tentar completá-lo antes de começar é desperdício: boa parte dos itens mudará ou será descartada com o que se aprende nas primeiras Sprints. O Product Owner mantém o topo nítido e aceita que a base seja uma lista de intenções.

Uma imagem útil é a do iceberg: pequeno e detalhado no topo, largo e vago embaixo. Se o backlog tem duzentos itens igualmente detalhados, alguém gastou tempo demais especificando o que talvez nunca seja feito.

O que faz um item estar pronto

• Claro
  O time entende o que é e por quê, sem precisar de uma reunião para decifrar.
• Pequeno
  Cabe em uma Sprint com folga, de preferência em poucos dias.
• Valioso
  Tem ligação explícita com a Meta do Produto ou com uma hipótese a testar.
• Testável
  Há critérios de aceitação que permitem dizer se está pronto.

Refinamento: a atividade que ninguém vê

O refinamento não é um evento do Scrum; é uma atividade contínua. Muitos times reservam uma fatia da Sprint para olhar os itens que virão nas próximas duas ou três Sprints; a versão de 2017 do Guia do Scrum sugeria até 10% da capacidade, e a de 2020 deixou a proporção a critério do time. Nessa conversa, o Product Owner explica o porquê, os Developers perguntam, o item é quebrado se for grande, estimado se for útil, e ganha critérios de aceitação.

• Quem participa: o Product Owner sempre; os Developers conforme o item; especialistas quando necessário.
• O que sai: itens menores, mais claros e ordenados; às vezes, itens removidos.
• O que não é: uma reunião de especificação em que o Product Owner dita e o time anota.

Sinais de um backlog doente

Imagine a geladeira de uma casa. Se está lotada de itens vencidos no fundo e o que se usa fica perdido no meio, ninguém encontra nada e tudo parece velho. O backlog adoece do mesmo jeito: itens de dois anos atrás que ninguém tem coragem de apagar, duplicatas, pedidos sem contexto, tudo com a mesma etiqueta de urgente. Limpar é parte do trabalho do Product Owner, e apagar um item antigo costuma ser mais valioso do que adicionar um novo.

Com o backlog saudável, o próximo capítulo trata de como escrever cada item para que o time o entenda: histórias de usuário e critérios de aceitação.