Neste módulo
Por que User Stories importam?
Uma User Story mal escrita é a causa raiz de boa parte dos retrabalhos em desenvolvimento. Quando o DEV vai codificar sem critérios claros, ele inventa o comportamento. Quando o analista não pensa nos casos de exceção, eles aparecem em produção.
Uma boa User Story não é um favor ao DEV — é proteção para o próprio analista. Ela documenta o que foi combinado e serve de critério de aceite na validação em homologação.
Anatomia completa de uma US de qualidade
Narrativa (Como / Quero / Para que)
✗ Exemplo ruim
Como usuário, quero fazer login no sistema.
Problemas: "Usuário" é vago. Não há valor de negócio. Sem critérios. O DEV vai implementar o que achar melhor.
✓ Exemplo bom
Como operador de caixa, quero autenticar no sistema com CPF e senha, para que eu acesse apenas as funcionalidades do meu perfil e o acesso indevido a dados sensíveis seja prevenido.
Elementos obrigatórios
Título
Verbo no infinitivo + Objeto. Ex: "Autenticar operador de caixa". Máximo 60 caracteres.
Narrativa
Como [persona específica], quero [ação clara], para que [valor de negócio concreto].
Regras de negócio
O que o sistema DEVE fazer, sempre, sem exceção. Mínimo 5 regras, numeradas, mensuráveis.
Critérios de aceite
Cenários testáveis em Gherkin: 1 feliz + 2 alternativos + 2 de exceção = mínimo.
Fora do escopo
O que esta US NÃO cobre. Evita scope creep e mal-entendidos com o DEV.
Dependências
USs anteriores, APIs ou serviços necessários para implementar esta US.
Regras de ouro do Gherkin
✗ Evitar
Dado que o usuário fez login no sistema
Quando preenche o formulário, valida e clica em confirmar
Então o pedido é salvo corretamente
✓ Correto
Dado que o usuário está autenticado como Vendedor
Quando clica em "Confirmar Pedido"
Então o sistema exibe "Pedido registrado — PED-2025-000123"
Modelo completo — copie e use
## US-[NÚMERO]: [TÍTULO] **Como** [persona específica], **quero** [ação clara], **para que** [valor de negócio concreto]. --- ### Regras de negócio 1. [Regra mensurável] 2. [Regra mensurável] ### Critérios de aceite **Cenário 1: [Nome do cenário feliz]** - Dado que [pré-condição] - Quando [ação do usuário] - Então [resultado esperado] **Cenário 2: [Alternativo]** ... **Cenário 3: [Exceção]** ... ### Casos de exceção - [Situação]: [comportamento esperado] ### Fora do escopo - [O que NÃO será feito nesta US] ### Dependências - [US anterior / API / Serviço] ### Definition of Done - [ ] Critérios validados pelo analista em homologação - [ ] Testes unitários escritos e passando - [ ] Documentação atualizada
Como a IA entra nesse processo
| Etapa | Sem IA | Com IA |
|---|---|---|
| Escrever a narrativa | 10 min | 2 min |
| Levantar regras de negócio | 30 min (reuniões) | IA sugere, analista valida |
| Escrever cenários Gherkin | 45 min | 10 min |
| Mapear casos de exceção | Frequentemente esquecidos | IA sempre levanta |
| Revisar consistência | Manual, propenso a erros | IA identifica contradições |
Prompts para escrever User Stories com IA
Quando usar: Você tem apenas o rascunho da funcionalidade e quer transformar em US completa.
Você é analista de negócio sênior especializado em sistemas [TIPO DO SISTEMA].
Vou te descrever uma funcionalidade de forma bruta.
Transforme em uma User Story completa e profissional.
Contexto do sistema: [descreva em 2-3 linhas]
Persona: [quem usa essa funcionalidade]
Ideia bruta: [descreva com suas palavras]
Gere a User Story com:
1. Título no formato [Verbo + Objeto]
2. Narrativa (Como / Quero / Para que)
3. Mínimo 5 regras de negócio
4. Critérios de aceite em Gherkin: cenário feliz
+ pelo menos 2 alternativos + 2 de exceção
5. Casos de exceção não cobertos pelos cenários
6. Fora do escopo desta US
7. Dependências prováveis
Se faltar informação, marque [A DEFINIR] e explique.
Formato de saída: Markdown.
Quando usar: Você escreveu a US e quer revisar antes de passar ao DEV.
Você é analista de negócio fazendo revisão de qualidade (QA de documentação).
Analise a User Story abaixo e identifique:
1. Informações ausentes ou vagas
2. Regras de negócio que provavelmente estão faltando
3. Cenários de exceção não cobertos
4. Contradições internas
5. Pontos que vão gerar dúvida no DEV
Para cada problema encontrado, sugira como corrigir.
[COLE A USER STORY AQUI]
Quando usar: Você tem uma funcionalidade grande e precisa dividir em entregas.
Você é analista de negócio. Recebi o seguinte épico para detalhar:
Épico: [NOME DO ÉPICO]
Descrição: [DESCREVA]
Contexto: [SISTEMA E NEGÓCIO]
Faça:
1. Liste todas as User Stories necessárias (5 a 15 USs)
2. Para cada US: título, narrativa e 3 principais critérios
3. Sugira ordem de implementação por dependência
4. Identifique quais são MVP e quais são melhorias
Formato: Markdown, uma seção por US.
Quando usar: Você já tem as regras de negócio e quer apenas os critérios de aceite.
Tenho as seguintes regras de negócio para [NOME DA FUNCIONALIDADE]:
[COLE AS REGRAS AQUI]
Gere critérios de aceite em Gherkin (Dado/Quando/Então) para:
- O cenário principal (caminho feliz)
- Todos os cenários alternativos relevantes
- Todos os cenários de erro e exceção
Para cada cenário: nome descritivo e "Então" específico e testável.
Evite "Então o sistema funciona corretamente".
Exemplo completo gerado com IA
Contexto do exemploSistema de gestão de pedidos B2B. Prompt P-US-01 usado com persona "Vendedor interno" e funcionalidade "Registrar pedido de venda manual".
## US-047: Registrar pedido de venda manual **Como** vendedor interno, **quero** registrar um novo pedido de venda manualmente, **para que** o pedido entre no fluxo de aprovação e separação sem depender de integração com e-commerce. --- ### Regras de negócio 1. O cliente deve estar com status "Ativo" para registrar o pedido 2. Todo pedido deve ter ao menos 1 item com quantidade ≥ 1 3. O sistema valida o estoque em tempo real — se insuficiente, exibe alerta mas permite salvar como "Pendência de estoque" 4. Desconto máximo por item: 15% sem aprovação do gerente; acima disso vai para fila de aprovação gerencial 5. Campo "Observações" obrigatório quando desconto > 10% 6. Número do pedido gerado automaticamente: PED-AAAA-NNNNNN 7. Pedidos ≥ R$ 10.000 → status "Aguardando aprovação"; abaixo → "Aprovado automaticamente" ### Critérios de aceite **Cenário 1: Pedido aprovado automaticamente** - Dado que o vendedor está em "Novo Pedido" - E o cliente está ativo, itens com estoque, valor < R$ 10.000 - Quando clica em "Confirmar Pedido" - Então o sistema salva com status "Aprovado automaticamente" - E exibe o número gerado (ex: PED-2025-000123) - E envia e-mail de confirmação ao cliente **Cenário 2: Pedido acima do limite — vai para aprovação** - Dado que o valor total é R$ 12.500 - Quando confirma o pedido - Então salva com status "Aguardando aprovação" - E notifica o gestor por e-mail - E exibe "Pedido registrado. Aguardando aprovação do gestor." **Cenário 3: Item sem estoque** - Dado que um item tem estoque zero - Quando tenta confirmar - Então exibe alerta "Item [X] sem estoque disponível" - E oferece: remover o item OU salvar com "Pendência de estoque" ### Casos de exceção - Timeout na validação de estoque: impede salvamento, solicita retry - Produto descontinuado: rejeita com "Produto indisponível para venda" ### Fora do escopo - Pedidos via integração e-commerce (US-048) - Aprovação pelo gestor (US-052) - Geração de nota fiscal (US-061) ### Dependências - US-012: Cadastro de clientes (deve estar implementada) - US-031: API de consulta de estoque disponível