6 min leitura • Guide 141 of 877
Criando User Stories Efetivas com Critérios Aceitação
User stories devem comunicar o que usuários precisam e por quê, permitindo times desenvolvimento implementar soluções enquanto testers verificam que a coisa certa foi construída. Stories mal escritas criam confusão, retrabalho, e features entregues que erram o alvo. Stories claras com critérios aceitação precisos eliminam ambiguidade e aceleram entrega.
Fundamentos User Story
O Formato Padrão
ESTRUTURA USER STORY:
┌─────────────────────────────────────────────────────────────┐
│ ANATOMIA BOA USER STORY │
├─────────────────────────────────────────────────────────────┤
│ │
│ FORMATO CLÁSSICO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Como um [tipo de usuário] ││
│ │ Eu quero [alguma capacidade] ││
│ │ Para que [valor negócio/benefício] ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ POR QUE CADA PARTE IMPORTA: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ "Como um [usuário]": ││
│ │ • Clarifica perspectiva (admin ≠ cliente) ││
│ │ • Habilita empatia durante implementação ││
│ │ • Ajuda identificar edge cases diferentes usuários ││
│ │ ││
│ │ "Eu quero [capacidade]": ││
│ │ • Descreve necessidade, não solução ││
│ │ • Permite implementação criativa ││
│ │ • Foca em resultado, não mecanismo ││
│ │ ││
│ │ "Para que [benefício]": ││
│ │ • Explica POR QUÊ (frequentemente esquecido) ││
│ │ • Habilita melhores soluções ││
│ │ • Ajuda discussões priorização ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ EXEMPLOS BONS vs RUINS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ❌ Ruim: "Adicionar botão exportar na página relatórios"││
│ │ (Especifica solução, sem usuário, sem por quê) ││
│ │ ││
│ │ ✅ Bom: "Como gerente marketing, quero exportar ││
│ │ relatórios campanha para CSV para que eu possa ││
│ │ analisar performance na nossa ferramenta BI sem ││
│ │ copiar manualmente" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Escrevendo Critérios Aceitação
Definindo "Pronto" Precisamente
PADRÕES CRITÉRIOS ACEITAÇÃO:
┌─────────────────────────────────────────────────────────────┐
│ FORMATO DADO-QUANDO-ENTÃO │
├─────────────────────────────────────────────────────────────┤
│ │
│ ESTRUTURA: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Dado [pré-condição/contexto] ││
│ │ Quando [ação/trigger] ││
│ │ Então [resultado esperado] ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ EXEMPLO PARA STORY EXPORTAR: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Critério 1: Exportação básica ││
│ │ Dado que estou visualizando relatório campanha ││
│ │ Quando clico "Exportar para CSV" ││
│ │ Então um arquivo CSV baixa com todos dados visíveis ││
│ │ ││
│ │ Critério 2: Tratamento range datas ││
│ │ Dado que filtrei relatório por range datas ││
│ │ Quando exporto para CSV ││
│ │ Então apenas dados filtrados estão incluídos ││
│ │ ││
│ │ Critério 3: Tratamento dados grandes ││
│ │ Dado que relatório tem mais de 10.000 linhas ││
│ │ Quando exporto para CSV ││
│ │ Então recebo link por email ao invés de download direto ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Templates Tarefas GitScrum
Padronizando Estrutura Story
SETUP TEMPLATE TAREFA:
┌─────────────────────────────────────────────────────────────┐
│ CRIANDO TEMPLATES STORY REUTILIZÁVEIS │
├─────────────────────────────────────────────────────────────┤
│ │
│ TEMPLATE USER STORY: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Título: [Feature] - [Descrição breve] ││
│ │ ││
│ │ Descrição: ││
│ │ ## User Story ││
│ │ Como um [tipo usuário] ││
│ │ Eu quero [capacidade] ││
│ │ Para que [benefício] ││
│ │ ││
│ │ ## Contexto ││
│ │ [Qualquer contexto que ajude entendimento] ││
│ │ ││
│ │ ## Critérios Aceitação ││
│ │ ### Critério 1: [Nome] ││
│ │ Dado [contexto] ││
│ │ Quando [ação] ││
│ │ Então [resultado] ││
│ │ ││
│ │ ## Fora de Escopo ││
│ │ [Explicitamente o que esta story NÃO inclui] ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ITENS CHECKLIST: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Definição de Pronto: ││
│ │ ☐ Todos critérios aceitação atendidos ││
│ │ ☐ Código revisado e aprovado ││
│ │ ☐ Testes unitários escritos e passando ││
│ │ ☐ Documentação atualizada ││
│ │ ☐ Sign-off QA recebido ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Dimensionando Stories
Tornando Stories Trabalháveis
DIVIDINDO STORIES:
┌─────────────────────────────────────────────────────────────┐
│ DIMENSIONANDO STORIES CORRETAMENTE │
├─────────────────────────────────────────────────────────────┤
│ │
│ GUIAS TAMANHO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Muito grande (Épico): ││
│ │ • Leva mais de uma sprint ││
│ │ • Tem múltiplos resultados usuário distintos ││
│ │ • Contém "e" na cláusula eu quero ││
│ │ ││
│ │ Tamanho certo (Story): ││
│ │ • Completável em 1-3 dias ││
│ │ • Único resultado usuário ││
│ │ • Testável independentemente ││
│ │ ││
│ │ Muito pequena (Tarefa): ││
│ │ • Sem valor usuário por si só ││
│ │ • Detalhe implementação puro ││
│ │ • "Criar tabela banco dados" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ TÉCNICAS DIVISÃO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Por passo workflow: ││
│ │ Épico: "Usuário pode gerenciar perfil" ││
│ │ → Story 1: Visualizar perfil ││
│ │ → Story 2: Editar info básica ││
│ │ → Story 3: Alterar senha ││
│ │ → Story 4: Upload avatar ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘