8 min leitura • Guide 381 of 877
Escrita de User Stories
User stories capturam o que usuários precisam em um formato que equipes podem agir. Boas stories comunicam valor claramente e permitem bom planejamento. Stories ruins criam confusão e expectativas frustradas.
Estrutura da Story
| Componente | Propósito | Obrigatório |
|---|---|---|
| Papel do usuário | Quem se beneficia | Sim |
| Objetivo | O que quer | Sim |
| Benefício | Por que importa | Sim |
| Critérios de aceite | Como verificar | Sim |
Formato de Story
Template Padrão
FORMATO DE USER STORY:
┌─────────────────────────────────────────────────────────────┐
│ │
│ O TEMPLATE: │
│ ─────────── │
│ Como [tipo de usuário] │
│ Eu quero [objetivo/capacidade] │
│ Para que [benefício/valor] │
│ │
│ Critérios de Aceite: │
│ ├── Dado [contexto] │
│ ├── Quando [ação] │
│ └── Então [resultado esperado] │
│ (múltiplos critérios) │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ BOM EXEMPLO: │
│ ───────────── │
│ Como cliente logado │
│ Eu quero salvar meu carrinho de compras │
│ Para que eu possa voltar depois para completar a compra │
│ │
│ Critérios de Aceite: │
│ ├── Dado que tenho itens no meu carrinho │
│ │ Quando navego para fora e volto │
│ │ Então meus itens do carrinho são preservados │
│ │ │
│ ├── Dado que estou deslogado │
│ │ Quando logo de volta │
│ │ Então meu carrinho é restaurado │
│ │ │
│ └── Dado que meu carrinho foi salvo por 30 dias │
│ Quando logo │
│ Então vejo mensagem de itens expirados removidos │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ MAU EXEMPLO: │
│ ──────────── │
│ "Implementar persistência do carrinho" │
│ ├── Sem perspectiva do usuário │
│ ├── Sem declaração de valor │
│ ├── Sem critérios de aceite │
│ ├── Apenas uma tarefa │
│ └── Não é uma story │
└─────────────────────────────────────────────────────────────┘
Critérios INVEST
Checklist de Qualidade
CRITÉRIOS INVEST:
┌─────────────────────────────────────────────────────────────┐
│ │
│ I - INDEPENDENTE: │
│ ───────────────── │
│ ├── Pode ser feita sem outras stories │
│ ├── Ordem pode ser mudada │
│ ├── Equipe pode pegar qualquer uma do sprint │
│ └── Sem dependências bloqueantes │
│ │
│ N - NEGOCIÁVEL: │
│ ─────────────── │
│ ├── Detalhes podem ser discutidos │
│ ├── Não é um contrato │
│ ├── Início de conversa │
│ ├── Implementação flexível │
│ └── Colabore na solução │
│ │
│ V - VALIOSA: │
│ ──────────── │
│ ├── Entrega valor ao usuário/negócio │
│ ├── Benefício claro │
│ ├── Vale a pena fazer │
│ ├── Não é apenas tarefa técnica │
│ └── Centrada no usuário │
│ │
│ E - ESTIMÁVEL: │
│ ────────────── │
│ ├── Equipe pode dimensionar │
│ ├── Entendida o suficiente │
│ ├── Se não pode estimar, precisa refinamento │
│ ├── Perguntas respondidas │
│ └── Clareza para planejamento │
│ │
│ S - SMALL (PEQUENA): │
│ ──────────────────── │
│ ├── Cabe em um sprint │
│ ├── Idealmente 1-3 dias de trabalho │
│ ├── Stories grandes = dividir │
│ ├── Completável │
│ └── Escopo gerenciável │
│ │
│ T - TESTÁVEL: │
│ ────────────── │
│ ├── Critérios de aceite claros │
│ ├── Pode verificar quando done │
│ ├── Comportamento definido │
│ ├── Não vago │
│ └── Sabe quando está concluída │
└─────────────────────────────────────────────────────────────┘
Dividindo Stories
Padrões de Divisão
TÉCNICAS DE DIVISÃO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ POR ETAPAS DE WORKFLOW: │
│ ───────────────────── │
│ Story grande: "Gerenciar configurações de conta" │
│ │
│ Dividida: │
│ 1. Ver configurações atuais │
│ 2. Editar informações de perfil │
│ 3. Mudar senha │
│ 4. Gerenciar notificações │
│ 5. Deletar conta │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ POR TIPOS DE USUÁRIO: │
│ ───────────────────── │
│ Story grande: "Dashboard para usuários" │
│ │
│ Dividida: │
│ 1. Dashboard de desenvolvedor (minhas tarefas, PRs) │
│ 2. Dashboard de gerente (métricas, velocity) │
│ 3. Dashboard de stakeholder (status de alto nível) │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ POR OPERAÇÕES CRUD: │
│ ─────────────────── │
│ Story grande: "Gerenciar posts do blog" │
│ │
│ Dividida: │
│ 1. Criar novo post │
│ 2. Listar posts existentes │
│ 3. Editar post │
│ 4. Deletar post │
│ 5. Publicar/despublicar post │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ POR HAPPY PATH VS EDGE CASES: │
│ ───────────────────────────── │
│ Story grande: "Processar pagamento" │
│ │
│ Dividida: │
│ 1. Processar pagamento bem-sucedido (happy path) │
│ 2. Lidar com cartão recusado │
│ 3. Lidar com timeout da rede │
│ 4. Suportar retry │
│ 5. Gerar recibo │
└─────────────────────────────────────────────────────────────┘
Critérios de Aceite
Escrevendo Bons Critérios
CRITÉRIOS DE ACEITE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ FORMATO DADO-QUANDO-ENTÃO: │
│ ────────────────────────── │
│ │
│ Dado [estado inicial/contexto] │
│ Quando [ação/evento acontece] │
│ Então [resultado esperado] │
│ │
│ EXEMPLOS: │
│ ────────── │
│ │
│ AC1: Login bem-sucedido │
│ Dado que sou usuário cadastrado │
│ Quando insiro email e senha corretos │
│ Então sou redirecionado para o dashboard │
│ │
│ AC2: Senha incorreta │
│ Dado que sou usuário cadastrado │
│ Quando insiro senha incorreta │
│ Então vejo mensagem "Credenciais inválidas" │
│ E posso tentar novamente │
│ │
│ AC3: Bloqueio de conta │
│ Dado que errei senha 5 vezes │
│ Quando tento login novamente │
│ Então conta é bloqueada por 15 minutos │
│ E recebo email de segurança │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ BOAS PRÁTICAS: │
│ │
│ ✓ Específico e mensurável │
│ ✓ Escrito da perspectiva do usuário │
│ ✓ Testável │
│ ✓ 3-8 critérios por story │
│ │
│ ✗ Muito vago ("sistema deve ser rápido") │
│ ✗ Muito técnico ("usar PostgreSQL") │
│ ✗ Detalhe de UI ("botão azul 120px") │
└─────────────────────────────────────────────────────────────┘
Erros Comuns
ERROS A EVITAR:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ERRO 1: STORY TÉCNICA │
│ ───────────────────── │
│ ❌ "Como desenvolvedor, quero refatorar o módulo auth" │
│ │
│ Problema: Não há valor para usuário final │
│ │
│ ✅ Expresse em termos de valor: │
│ "Como usuário, quero login rápido e confiável" │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ERRO 2: MUITO GRANDE │
│ ──────────────────── │
│ ❌ "Como admin, quero gerenciar todo o sistema" │
│ │
│ Problema: Não cabe em um sprint, impossível estimar │
│ │
│ ✅ Divida em stories menores e focadas │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ERRO 3: SEM BENEFÍCIO CLARO │
│ ─────────────────────────── │
│ ❌ "Como usuário, quero um botão de exportar" │
│ │
│ Problema: Por quê? O que resolve? │
│ │
│ ✅ "Como analista, quero exportar dados para que │
│ eu possa analisar em minhas ferramentas" │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ERRO 4: ESPECIFICAÇÃO DE IMPLEMENTAÇÃO │
│ ────────────────────────────────────── │
│ ❌ "Como usuário, quero um dropdown com 3 opções │
│ em Bootstrap azul..." │
│ │
│ Problema: Dita implementação, não permite colaboração │
│ │
│ ✅ Descreva o problema, não a solução │
└─────────────────────────────────────────────────────────────┘