Como escrever boas User Stories

Uma User Story mal escrita é a raiz de estimativas erradas, entregas fora do esperado e frustração do time. Uma boa User Story, por outro lado, é clara, acionável e testável.

O formato básico

Como [tipo de usuário], quero [ação] para [benefício/valor].

Exemplo bom

Como cliente do e-commerce, quero salvar múltiplos endereços de entrega para não precisar digitar todo pedido novo.

Exemplo ruim

“Adicionar tabela de endereços no banco de dados.”

O exemplo ruim descreve uma implementação, não uma necessidade do usuário. O bom foca no valor.

O framework INVEST

I — Independente

Cada história pode ser entregue sem depender de outras.

Ruim: “Criar API de login” e “Criar frontend de login” como histórias separadas. Bom: “Como usuário, quero fazer login para acessar minha conta” — inclui frontend e backend.

N — Negociável

Os detalhes são discutíveis, não especificações fixas.

Ruim: “O botão deve ser azul #0066CC, cantos arredondados 4px, fonte 14px.” Bom: “O botão de salvar deve ser visualmente destacado na página.” — detalhes são discutidos com o designer.

V — Valiosa

Entrega valor real ao usuário ou ao negócio.

Ruim: “Refatorar o módulo de pagamento.” Bom: “Como cliente, quero que o pagamento seja processado em menos de 3 segundos para ter uma experiência fluída.”

E — Estimável

O time tem informação suficiente para estimar.

Ruim: “Melhorar performance do sistema.” (o quê? quanto?) Bom: “Como usuário, quero que a página de produtos carregue em menos de 2 segundos.”

P — Pequena

Cabe em um sprint. Se não cabe, quebre.

Ruim: “Como administrador, quero gerenciar usuários, permissões, grupos e auditoria.” (4 coisas em uma) Bom: 4 histórias separadas, cada uma com foco.

T — Testável

Tem critérios de aceitação claros.

Ruim: “O sistema deve ser rápido.” Bom: “A busca retorna resultados em menos de 500ms para 95% das queries.”

Critérios de aceitação

Cada história precisa de critérios de aceitação. Formato comum: Given/When/Then.

Dado que estou na página de checkout Quando clico em “Salvar endereço” Então o endereço é adicionado à minha lista de endereços E aparece mensagem de confirmação

Story Points e User Stories

A história deve ser estimada com Planning Poker após estar bem escrita e com critérios de aceitação definidos. Se o time não consegue estimar, a história precisa de mais refinamento, não de um chute.

Épicos vs Histórias

Épico é uma história grande demais para um sprint. Deve ser quebrada:

Épico: “Como cliente, quero um programa de fidelidade completo.”

Histórias derivadas:

1. Como cliente, quero acumular pontos a cada compra.
2. Como cliente, quero consultar meu saldo de pontos.
3. Como cliente, quero trocar pontos por cupons de desconto.
4. Como administrador, quero configurar a taxa de acumulação de pontos.

Conclusão

Boas User Stories são a base de estimativas precisas e entregas de valor. Invista tempo em escrevê-las corretamente — o retorno vem em sprints mais previsíveis e stakeholders mais satisfeitos.