Neste capítulo, você vai aprender a descrever itens do Product Backlog com histórias de usuário e critérios de aceitação, e a quebrar itens grandes em partes que cabem em uma Sprint. É a habilidade de escrita que separa um backlog que o time entende de um que o time precisa adivinhar.

História de usuário é uma forma curta de descrever um item do backlog a partir da perspectiva de quem o usa: quem é, o que quer e por quê. Critérios de aceitação são as condições observáveis que definem quando a história está completa. Juntos, dão ao time o suficiente para conversar e o necessário para verificar, sem virar especificação.

O modelo e o que ele esconde

O formato mais usado é “Como [persona], quero [ação] para [benefício]”. O valor não está no formato, está no benefício: é ele que permite ao time propor uma solução melhor do que a pedida. Uma história sem o “para” é só um pedido de funcionalidade. Uma história com o “para” claro pode ser atendida de várias formas, e a melhor delas às vezes nem é a que o Product Owner imaginou.

Histórias são lembretes de uma conversa, não substitutos dela. O que Ron Jeffries chamou de três Cs resume isso: cartão, conversa e confirmação. O cartão é pequeno de propósito.

Critérios de aceitação

• Observáveis
  Descrevem um comportamento que alguém consegue verificar, não uma intenção.
• Poucos
  Três a seis por história. Mais do que isso, a história é grande demais.
• No vocabulário do negócio
  “O cliente recebe o comprovante por e-mail”, não “o serviço retorna 200”.
• Escritos juntos
  Product Owner propõe, Developers e QA questionam e completam no refinamento.

Quebrar sem perder valor

Imagine uma pizza. Cortar em fatias mantém cada pedaço com massa, molho e cobertura; cortar em camadas entrega só a massa primeiro. Decompor um item do backlog segue a mesma lógica: cada parte deve entregar algo que o usuário perceba, não apenas “o banco de dados” ou “a tela”. Algumas formas de cortar:

• Por passo da jornada: primeiro buscar, depois comparar, depois comprar.
• Por regra de negócio: primeiro o caso simples, depois as exceções.
• Por persona: primeiro o cliente novo, depois o recorrente.
• Por dado: primeiro um tipo de pagamento, depois os outros.
• Por qualidade: primeiro funciona, depois fica rápido e bonito.

Definição de Pronto e de Preparado

Critérios de aceitação são específicos de cada item. A Definição de Pronto vale para todos: testes, revisão, documentação, deploy. Muitos times usam também uma Definição de Preparado, a lista do que um item precisa ter para entrar na Sprint. Nenhuma das duas substitui a conversa; as duas evitam que ela seja esquecida. No curso CSPO, cada equipe escreve histórias e critérios para o produto que definiu, e descobre como um “para” bem escrito muda a solução.

O próximo capítulo sai da escrita e entra na relação: como o Product Owner lida com stakeholders e como o papel se compara ao de gerente de produto.