6 min leitura • Guide 747 of 877
Escrevendo Melhores User Stories
Boas user stories comunicam intenção claramente. O GitScrum fornece templates e campos que ajudam times a escrever stories com o nível certo de detalhe.
Básicos de User Story
Formato da Story
ESTRUTURA DE USER STORY:
┌─────────────────────────────────────────────────────────────┐
│ │
│ FORMATO CLÁSSICO: │
│ │
│ Como um [tipo de usuário] │
│ Eu quero [algum objetivo] │
│ Para que [alguma razão/benefício] │
│ │
│ EXEMPLO: │
│ │
│ Como um gerente de projeto │
│ Eu quero exportar relatórios para PDF │
│ Para que eu possa compartilhar progresso com stakeholders │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ POR QUE ESTE FORMATO FUNCIONA: │
│ │
│ QUEM: Identifica o tipo de usuário │
│ → Ajuda a entender contexto │
│ │
│ O QUÊ: Declara a funcionalidade desejada │
│ → Objetivo claro │
│ │
│ POR QUÊ: Explica a necessidade subjacente │
│ → Habilita soluções alternativas │
│ → Previne "apenas construa o que eu disse" │
│ │
│ FORMATO ALTERNATIVO (se mais simples): │
│ │
│ "Permitir gerentes de projeto exportar relatórios PDF" │
│ │
│ O formato é uma ferramenta, não uma regra │
│ Clareza > seguir formato rigidamente │
└─────────────────────────────────────────────────────────────┘
Critérios INVEST
CHECKLIST INVEST:
┌─────────────────────────────────────────────────────────────┐
│ │
│ I - INDEPENDENTE │
│ Pode ser desenvolvida sem depender de outras stories │
│ ❌ "Depois que story A estiver pronta, podemos fazer B" │
│ ✅ Story B se sustenta sozinha │
│ │
│ N - NEGOCIÁVEL │
│ Detalhes podem ser discutidos e ajustados │
│ ❌ "Construa exatamente esta UI com estes 27 campos" │
│ ✅ "Usuário precisa configurar notificações" │
│ │
│ V - VALIOSA │
│ Entrega valor ao usuário ou negócio │
│ ❌ "Refatorar a camada de banco de dados" │
│ ✅ "Usuários experimentam carregamento mais rápido" │
│ │
│ E - ESTIMÁVEL │
│ Time pode estimar o esforço │
│ ❌ Muito vaga para dimensionar │
│ ✅ Clara o suficiente para discutir complexidade │
│ │
│ S - SMALL (Pequena) │
│ Cabe dentro de uma sprint │
│ ❌ "Construir todo o sistema de checkout" │
│ ✅ "Adicionar opção de pagamento com cartão" │
│ │
│ T - TESTÁVEL │
│ Pode verificar quando completa │
│ ❌ "Deixar o app mais rápido" │
│ ✅ "Página carrega em menos de 2 segundos" │
│ │
│ USE ISTO: Revise stories contra INVEST antes do planning │
└─────────────────────────────────────────────────────────────┘
Critérios de Aceitação
Escrevendo Critérios
EXEMPLOS DE CRITÉRIOS DE ACEITAÇÃO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ STORY: Como usuário, posso exportar meus dados para CSV │
│ │
│ CRITÉRIOS DE ACEITAÇÃO: │
│ │
│ ✅ BONS CRITÉRIOS: │
│ │
│ DADO que estou na página de grid de dados │
│ QUANDO clico no botão "Exportar" │
│ ENTÃO um arquivo CSV baixa para meu computador │
│ │
│ DADO que selecionei colunas específicas │
│ QUANDO exporto │
│ ENTÃO apenas colunas selecionadas aparecem no CSV │
│ │
│ DADO que o dataset tem 50.000 linhas │
│ QUANDO exporto │
│ ENTÃO a exportação completa em 30 segundos │
│ E vejo um indicador de progresso │
│ │
│ DADO que os dados contêm caracteres especiais │
│ QUANDO exporto e abro no Excel │
│ ENTÃO caracteres aparecem corretamente │
│ │
│ ❌ CRITÉRIOS RUINS: │
│ │
│ • "Exportação funciona" │
│ • "CSV é gerado" │
│ • "Usuário pode baixar" │
│ → Muito vagos, não testáveis │
└─────────────────────────────────────────────────────────────┘
Cobrindo Casos de Borda
PENSANDO EM EDGE CASES
══════════════════════
PERGUNTAS PARA FAZER:
─────────────────────────────────────
├── E se o input for vazio?
├── E se for muito grande?
├── E se for inválido?
├── E se a rede cair?
├── E se o usuário cancelar?
├── E se acontecer duas vezes?
└── E se não tiver permissão?
EXEMPLO - UPLOAD DE ARQUIVO:
─────────────────────────────────────
Happy path:
DADO usuário na página de upload
QUANDO seleciona PDF válido menor que 10MB
ENTÃO arquivo faz upload com sucesso
E nome aparece na lista
Edge cases:
DADO usuário seleciona arquivo maior que 10MB
QUANDO clica upload
ENTÃO vê erro "Arquivo muito grande"
E upload não prossegue
DADO usuário seleciona arquivo .exe
QUANDO clica upload
ENTÃO vê erro "Tipo de arquivo inválido"
DADO upload está em progresso
QUANDO rede desconecta
ENTÃO vê "Upload falhou. Tentar novamente?"
E pode tentar sem reselecionar arquivo
DADO usuário cancela durante upload
QUANDO clica "Cancelar"
ENTÃO upload para imediatamente
E arquivo parcial é removido
Refinamento de Stories
Processo de Refinamento
REFINAMENTO EFETIVO
═══════════════════
ANTES DA SESSÃO:
─────────────────────────────────────
PO prepara:
├── Stories para próximas 2 sprints
├── Critérios de aceitação iniciais
├── Mockups/wireframes se houver
├── Contexto de negócio
└── Priorização sugerida
DURANTE A SESSÃO:
─────────────────────────────────────
Time discute:
├── Entendimento comum da story
├── Critérios de aceitação completos?
├── Edge cases faltando?
├── Dependências técnicas?
├── Estimativa inicial
└── Story muito grande? Quebrar.
DEPOIS DA SESSÃO:
─────────────────────────────────────
├── Stories atualizadas no GitScrum
├── Critérios finalizados
├── Prontas para planning
└── Time alinhado
SINAIS DE STORY NÃO PRONTA:
─────────────────────────────────────
├── Muitas perguntas sem resposta
├── Critérios vagos
├── Time não consegue estimar
├── Dependências não resolvidas
├── Escopo não claro
└── → Volta para refinamento
Quebrando Stories Grandes
SPLITTING STORIES
═════════════════
STORY GRANDE DEMAIS:
─────────────────────────────────────
"Como usuário, quero gerenciar minha conta"
Problema: Muito ampla, não cabe em sprint
TÉCNICAS DE SPLIT:
─────────────────────────────────────
1. Por funcionalidade:
├── Editar perfil
├── Mudar senha
├── Configurar notificações
├── Deletar conta
└── Cada uma é uma story
2. Por cenário:
├── Login com email
├── Login com Google
├── Login com Apple
└── Cada um independente
3. Por complexidade:
├── Versão simples primeiro
├── Adicionar validações
├── Adicionar edge cases
└── Incrementalmente
4. Por dados:
├── Criar
├── Ler
├── Atualizar
├── Deletar
└── CRUD separado
REGRA DE OURO:
─────────────────────────────────────
Se não cabe em uma sprint,
quebre até caber.
Cada parte deve entregar valor.