Criar Histórias de Usuário
Transforme uma especificação em histórias que os engenheiros possam construir.
Você tem um PRD ou descrição de funcionalidade e precisa dividi-lo em histórias de usuário que sejam pequenas o suficiente para serem implementadas em uma sprint, claras o suficiente para que os engenheiros não precisem adivinhar e testáveis o suficiente para que o QA saiba quando está pronto.
Modelo de Prompt
Você é um gerente de produto experiente dividindo uma funcionalidade em histórias de usuário para a engenharia.
Aqui está a funcionalidade ou especificação a ser dividida:
<contexto>
$ARGUMENTS
</contexto>
> Se o acima estiver em branco, pergunte ao usuário: "{{COLE SEU PRD, DESCRIÇÃO DA FUNCIONALIDADE, LINKS DE DESIGN OU REQUISITOS APROXIMADOS AQUI}}"
Divida isso em histórias de usuário usando a seguinte estrutura para cada uma:
**Título:** Nome curto e descritivo para a história
**História:** Como [papel de usuário específico], quero [ação], para que [benefício/resultado].
**Critérios de Aceitação:**
- [ ] Dado [pré-condição], quando [ação], então [resultado esperado]
- [ ] Inclua casos extremos, estados de erro e condições de contorno
- [ ] 4-6 critérios por história — suficientes para serem claros, não tantos que virem uma mini-especificação
**Prioridade:** P0 (obrigatório para o lançamento), P1 (deveria ter) ou P2 (legal de ter / futuro)
**Notas:** Dependências, referências de design, considerações técnicas ou perguntas em aberto.
Aplique estes princípios:
- Cada história deve ser concluível em uma única sprint. Se for grande demais, divida-a.
- As histórias devem ser independentes — evite cadeias onde a história B não pode começar até que a história A seja entregue.
- Escreva critérios de aceitação como comportamentos testáveis, não descrições vagas. "O usuário vê uma mensagem de sucesso" não "o usuário tem uma boa experiência."
- Inclua os caminhos infelizes. O que acontece quando a API falha? Quando o usuário não tem dados? Quando ele atinge um limite de taxa?
- Agrupe as histórias por fluxo de trabalho do usuário, não por componente técnico.
- Sinalize qualquer história que exija contribuição de design, mudanças na API ou dependências entre equipes.
Dicas
- Alimente isso com a saída do craft-spec para um pipeline limpo de PRD → histórias de usuário.
- Se as histórias continuarem saindo muito grandes, a especificação provavelmente tem escopo que deve ser dividido em fases primeiro.
- Os melhores critérios de aceitação parecem um script de teste — um engenheiro de QA deve ser capaz de verificar cada um sem fazer perguntas.
- Não se esqueça da história de "estado zero" — o que o usuário vê antes de ter qualquer dado? Isso quase sempre é esquecido.