8 min leitura • Guide 611 of 877
Melhores Práticas de Escrita de User Stories
User stories são a unidade fundamental de trabalho no desenvolvimento ágil - descrevem o que usuários precisam de forma que desenvolvedores podem entender e entregar. Stories bem escritas são Independentes, Negociáveis, Valiosas, Estimáveis, Small (Pequenas) e Testáveis (INVEST).
Componentes de User Story
| Componente | Propósito | Obrigatório |
|---|---|---|
| Título | Referência rápida | Sim |
| Papel do usuário | Quem se beneficia | Sim |
| Ação | O que quer | Sim |
| Benefício | Por que importa | Sim |
| Critérios de Aceite | Definição de done | Sim |
| Notas | Contexto, detalhes | Opcional |
Formato de Story
ESTRUTURA DE USER STORY:
┌─────────────────────────────────────────────────────────────┐
│ │
│ FORMATO PADRÃO: │
│ ─────────────── │
│ Como [papel do usuário] │
│ Eu quero [ação/feature] │
│ Para que [benefício/valor] │
│ │
│ EXEMPLO: │
│ Como gerente de projeto │
│ Eu quero exportar relatórios de sprint para PDF │
│ Para que eu possa compartilhar progresso com stakeholders│
│ que não têm acesso ao sistema │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ PAPÉIS DE USUÁRIO: │
│ │
│ Seja específico sobre quem: │
│ │
│ ✗ Como usuário... │
│ ✓ Como gerente de projeto... │
│ ✓ Como visitante primeira vez... │
│ ✓ Como admin enterprise... │
│ ✓ Como desenvolvedor da equipe... │
│ │
│ Papéis diferentes = necessidades diferentes │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ A CLÁUSULA "PARA QUE": │
│ │
│ Parte mais importante - explica o valor │
│ │
│ ✗ "Para que eu possa exportar relatórios" │
│ (apenas repete a ação) │
│ │
│ ✓ "Para que eu possa compartilhar progresso com │
│ stakeholders que não têm acesso" │
│ (explica o benefício real) │
│ │
│ Se não consegue explicar por quê, questione se é necessário│
└─────────────────────────────────────────────────────────────┘
Critérios INVEST
CHECKLIST INVEST:
┌─────────────────────────────────────────────────────────────┐
│ │
│ INDEPENDENTE: │
│ ───────────── │
│ ✓ Pode ser desenvolvida em qualquer ordem │
│ ✓ Sem dependência de outras stories │
│ ✓ Pode ser lançada independentemente │
│ │
│ ✗ "Completar pagamento após story de checkout" │
│ ✓ "Processar pagamento do carrinho" │
│ (inclui o necessário para funcionar sozinha) │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ NEGOCIÁVEL: │
│ ─────────── │
│ ✓ Detalhes podem ser discutidos │
│ ✓ Não é especificação fixa │
│ ✓ Espaço para input técnico │
│ │
│ ✗ "Construa exatamente este wireframe" │
│ ✓ "Usuários precisam resetar senha facilmente" │
│ (equipe pode propor solução) │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ VALIOSA: │
│ ──────── │
│ ✓ Entrega valor ao usuário ou negócio │
│ ✓ Stakeholder pagaria por ela │
│ ✓ Pode explicar por que importa │
│ │
│ ✗ "Refatorar módulo de auth" │
│ (técnico, sem valor para usuário declarado) │
│ ✓ "Usuários podem fazer login em menos de 3 segundos" │
│ (valor é claro) │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ESTIMÁVEL: │
│ ────────── │
│ ✓ Equipe pode estimar o esforço │
│ ✓ Detalhe suficiente para dimensionar │
│ ✓ Não muito vaga │
│ │
│ ✗ "Melhorar o dashboard" │
│ (muito vago para estimar) │
│ ✓ "Adicionar botão de exportar ao dashboard que │
│ gera CSV dos dados visíveis" │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ SMALL (PEQUENA): │
│ ──────────────── │
│ ✓ Cabe em um sprint │
│ ✓ Pode ser completada em dias, não semanas │
│ ✓ Quebrável se muito grande │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ TESTÁVEL: │
│ ────────── │
│ ✓ Critérios de aceite claros │
│ ✓ Pode verificar se está done │
│ ✓ Definição objetiva de sucesso │
│ │
│ ✗ "Sistema deve ser rápido" │
│ (não testável objetivamente) │
│ ✓ "Dashboard carrega em menos de 2 segundos" │
│ (pode medir e verificar) │
└─────────────────────────────────────────────────────────────┘
Critérios de Aceite
ESCREVENDO CRITÉRIOS DE ACEITE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ FORMATO GIVEN-WHEN-THEN: │
│ ───────────────────────── │
│ │
│ Given [contexto/estado inicial] │
│ When [ação/evento] │
│ Then [resultado esperado] │
│ │
│ EXEMPLO: │
│ │
│ Story: Login de usuário │
│ │
│ AC1: Login bem-sucedido │
│ Given usuário cadastrado com email "joao@email.com" │
│ When insere email e senha corretos e clica "Entrar" │
│ Then é redirecionado para dashboard │
│ │
│ AC2: Senha incorreta │
│ Given usuário cadastrado │
│ When insere senha incorreta │
│ Then vê mensagem "Credenciais inválidas" │
│ And pode tentar novamente │
│ │
│ AC3: Bloqueio após tentativas │
│ Given usuário errou senha 5 vezes │
│ When tenta login novamente │
│ Then conta é bloqueada por 15 minutos │
│ And recebe email de segurança │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ QUANTOS CRITÉRIOS: │
│ │
│ • 3-8 critérios é típico │
│ • Menos de 3: pode estar faltando edge cases │
│ • Mais de 10: story provavelmente muito grande │
│ │
│ NÍVEL DE DETALHE: │
│ │
│ ✓ "Usuário vê mensagem de sucesso" │
│ ✗ "Mensagem de sucesso deve estar em fonte Arial 14px │
│ verde #00FF00 centralizada" │
│ (detalhe demais - deixe para design) │
└─────────────────────────────────────────────────────────────┘
Erros Comuns
ERROS A EVITAR:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ERRO 1: STORY TÉCNICA │
│ ───────────────────── │
│ ❌ "Como desenvolvedor, quero refatorar o código de auth"│
│ │
│ Problema: Não descreve valor para usuário final │
│ │
│ ✅ "Como usuário, quero fazer login rapidamente" │
│ (Technical work becomes implementation detail) │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ERRO 2: ESPECIFICAÇÃO DISFARÇADA │
│ ──────────────────────────────── │
│ ❌ "Como usuário, quero um botão azul de 120px×40px │
│ no canto superior direito que abre modal de 600px..."│
│ │
│ Problema: Dita implementação, não permite negociação │
│ │
│ ✅ "Como usuário, quero acessar configurações facilmente"│
│ (Team proposes solution) │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ERRO 3: ÉPICO DISFARÇADO │
│ ──────────────────────── │
│ ❌ "Como admin, quero gerenciar todo o sistema de usuários"│
│ │
│ Problema: Grande demais, precisa ser quebrada │
│ │
│ ✅ Quebre em stories menores (CRUD separado) │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ERRO 4: SEM VALOR CLARO │
│ ─────────────────────── │
│ ❌ "Como usuário, quero uma API de exportação" │
│ │
│ Problema: Por quê? O que resolve? │
│ │
│ ✅ "Como analista, quero exportar dados para analisar │
│ em minhas ferramentas externas" │
└─────────────────────────────────────────────────────────────┘
Stories no GitScrum
GERENCIANDO STORIES NO GITSCRUM:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ESTRUTURA RECOMENDADA: │
│ │
│ TÍTULO: │
│ Exportar relatórios para PDF │
│ │
│ DESCRIÇÃO: │
│ Como gerente de projeto │
│ Eu quero exportar relatórios de sprint para PDF │
│ Para que eu possa compartilhar com stakeholders │
│ que não têm acesso ao sistema │
│ │
│ CRITÉRIOS DE ACEITE: │
│ ☐ Botão "Exportar PDF" visível na página de relatórios │
│ ☐ PDF inclui todas as métricas do sprint │
│ ☐ PDF tem branding da empresa │
│ ☐ Download inicia automaticamente │
│ ☐ Funciona em Chrome, Firefox, Safari │
│ │
│ NOTAS/CONTEXTO: │
│ • Stakeholders preferem PDF porque podem anotar │
│ • Ver mock no Figma [link] │
│ • Similar à exportação que Trello tem │
│ │
│ LABELS: │
│ [feature] [relatórios] [pedido-cliente] │
│ │
│ PONTOS: 5 │
└─────────────────────────────────────────────────────────────┘