Escrevendo User Stories Efetivas

User stories não são documentos de requisitos—são placeholders para conversas. Uma boa user story captura quem precisa do que e por quê, é pequena o suficiente para completar em uma sprint e convida discussão sobre os detalhes. Este guia cobre como escrever stories que realmente ajudam times a construir a coisa certa.

Elementos da Story

Formato da Story

O Template Clássico

TEMPLATE DE USER STORY
══════════════════════

FORMATO:
─────────────────────────────────────
Como um [tipo de usuário]
Eu quero [objetivo/desejo]
Para que [benefício/valor]

Critérios de Aceitação:
├── Dado [contexto], quando [ação], então [resultado]
├── Dado [contexto], quando [ação], então [resultado]
└── ...

EXEMPLO:
─────────────────────────────────────
Como um comprador frequente
Eu quero salvar itens na minha lista de desejos
Para que eu possa encontrá-los facilmente depois para comprar

Critérios de Aceitação:
├── Dado que estou em uma página de produto
│   Quando clico "Adicionar à Lista de Desejos"
│   Então o item aparece na minha lista
│
├── Dado que estou vendo minha lista de desejos
│   Quando clico "Adicionar ao Carrinho" em um item
│   Então o item move para meu carrinho
│
├── Dado que tenho itens na minha lista de desejos
│   Quando retorno na próxima semana
│   Então meus itens ainda estão lá
│
└── Dado que um item fica indisponível
    Quando vejo minha lista de desejos
    Então vejo "Fora de estoque" naquele item

COMPONENTES EXPLICADOS:
─────────────────────────────────────
TIPO DE USUÁRIO:
├── Para quem é isso?
├── Seja específico: "Novo usuário" vs "Admin" vs "Assinante premium"
├── Persona se você tiver
└── Ajuda a priorizar e desenhar

OBJETIVO:
├── O que eles querem fazer?
├── Capacidade funcional
├── Não COMO, apenas O QUE
└── Linguagem do usuário, não técnica

BENEFÍCIO:
├── Por que isso importa?
├── A motivação real
├── Ajuda a entender trade-offs
└── Às vezes revela soluções melhores

Critérios INVEST

Checagem de Qualidade

CRITÉRIOS INVEST
════════════════

I - INDEPENDENTE
─────────────────────────────────────
Stories devem ser completáveis sozinhas.
Não: "Usuário pode pagar (requer story do carrinho)"
Sim: Cada story entregável independentemente

Se dependências existem, note mas minimize.

N - NEGOCIÁVEL
─────────────────────────────────────
Stories são iniciadores de conversa, não contratos.
Detalhes emergem através de discussão.
Não especifique demais antecipadamente.
Espaço para input do time na implementação.

V - VALIOSA
─────────────────────────────────────
Cada story entrega valor a alguém.
Não: "Instalar banco de dados" (sem valor direto ao usuário)
Sim: "Usuário pode salvar preferências" (valor)

Trabalho técnico pode ser story, mas linke ao valor.

E - ESTIMÁVEL
─────────────────────────────────────
Time pode estimar o esforço.
Se não estimável:
├── Muito vaga → Precisa mais detalhe
├── Muito grande → Precisa quebrar
└── Muito nova → Spike para investigar

S - SMALL (Pequena)
─────────────────────────────────────
Completável em poucos dias.
Idealmente 1-5 story points.
Se maior que 8 points, quebre.
Cabe confortavelmente em uma sprint.

T - TESTÁVEL
─────────────────────────────────────
Você sabe quando está pronta.
Critérios de aceitação são verificáveis.
QA pode escrever testes.
Não é opinião, é sim/não.

Escrevendo Boas Stories

Foco no Usuário

PERSPECTIVA DO USUÁRIO
══════════════════════

❌ PERSPECTIVA TÉCNICA:
─────────────────────────────────────
"Como sistema, eu quero um endpoint de API
para que dados possam ser recuperados."

↓ Sem valor claro, quem se beneficia?

✅ PERSPECTIVA DO USUÁRIO:
─────────────────────────────────────
"Como gerente de vendas
eu quero ver relatório de performance da equipe
para que eu possa identificar quem precisa de coaching."

↓ Valor claro, decisão acionável

CONVERTENDO TÉCNICO PARA USUÁRIO:
─────────────────────────────────────
Técnico: "Implementar cache Redis"
Usuário: "Como usuário, quero que páginas 
         carreguem rápido mesmo com tráfego alto"

Técnico: "Refatorar módulo de autenticação"
Usuário: "Como usuário, quero login mais rápido
         e menos sessões expiradas"

O trabalho técnico continua existindo,
mas é justificado pelo valor ao usuário.

Quebrando Stories Grandes

TÉCNICAS DE SPLITTING
═════════════════════

STORY MUITO GRANDE:
─────────────────────────────────────
"Como admin, quero gerenciar todos os usuários"

Problema: Muito ampla, não cabe em sprint

TÉCNICAS:
─────────────────────────────────────
1. POR OPERAÇÃO (CRUD):
   ├── Admin pode criar usuário
   ├── Admin pode visualizar usuários
   ├── Admin pode editar usuário
   └── Admin pode desativar usuário

2. POR TIPO DE USUÁRIO:
   ├── Admin gerencia usuários básicos
   ├── Admin gerencia outros admins
   └── Admin gerencia contas de serviço

3. POR COMPLEXIDADE:
   ├── Gerenciamento básico (criar/editar nome)
   ├── Gerenciamento de permissões
   └── Gerenciamento de integração SSO

4. POR CENÁRIO:
   ├── Happy path: criar usuário simples
   ├── Criar usuário com permissões especiais
   └── Criar usuário com import de CSV

REGRA DE OURO:
─────────────────────────────────────
Cada split deve:
├── Entregar valor ao usuário
├── Ser deployável sozinha
├── Caber em uma sprint
└── Ser testável

Anti-Patterns

O QUE EVITAR
════════════

STORY TÉCNICA SEM VALOR:
─────────────────────────────────────
❌ "Como dev, quero refatorar o código"
❌ "Como sistema, quero banco otimizado"
❌ "Atualizar dependências"

STORY MUITO VAGA:
─────────────────────────────────────
❌ "Melhorar a experiência"
❌ "Deixar mais rápido"
❌ "Resolver problemas de performance"

STORY MUITO GRANDE:
─────────────────────────────────────
❌ "Como usuário, quero ecommerce completo"
❌ "Implementar sistema de pagamentos"
❌ "Redesign do produto inteiro"

STORY SEM CRITÉRIOS:
─────────────────────────────────────
❌ Story sem acceptance criteria
❌ "Funciona" como único critério
❌ Critérios não verificáveis

Artigos Relacionados

• Writing Better User Stories
• Writing Clear Acceptance Criteria
• Backlog Refinement Best Practices
• User Story Mapping
• Sprint Planning Best Practices