Download do Template
Baixe o template de User Story em Markdown. Estrutura completa para historias de usuario com suporte a agentes de IA.
📋 Anatomia de uma Story
Uma User Story no GIPM nao e apenas um "cartao" com uma frase. E um documento vivo que acompanha todo o ciclo de vida da feature, desde a concepcao ate a validacao final. A estrutura e desenhada para suportar tanto desenvolvedores humanos quanto agentes de IA.
Estrutura Completa de uma Story GIPM
Exemplo de Story Formatada
✅ Criterios de Aceitacao
Criterios de Aceitacao (AC) sao o contrato de "done". Eles definem exatamente quando uma story pode ser considerada completa. No GIPM, cada AC deve ser verificavel objetivamente - nada de "funciona bem" ou "e rapido".
❌ ACs Ruins
- • "O sistema deve ser rapido"
- • "A interface deve ser bonita"
- • "Funciona corretamente"
- • "Usuario consegue fazer login"
✅ ACs Bons
- • "Resposta em menos de 200ms"
- • "Segue Design System v2.0"
- • "Retorna status 200 com token JWT"
- • "Email invalido mostra erro em vermelho"
💡 Formato GIVEN-WHEN-THEN
Use o formato GWT para ACs mais precisos e testaveis automaticamente:
📝 Tarefas e Subtarefas
Cada Story deve ser quebrada em tarefas atomicas - acoes especificas que podem ser completadas de forma independente. No GIPM, cada tarefa referencia qual Acceptance Criteria ela atende, criando rastreabilidade total.
Exemplo de Task Breakdown
Por que referenciar ACs nas Tasks?
- • Rastreabilidade - Sabe-se exatamente qual requisito cada tarefa atende
- • Validacao - QA sabe o que testar apos cada task
- • Cobertura - Facilita identificar se todos os ACs estao cobertos
- • Priorizacao - Permite priorizar tasks de ACs criticos
📌 Notas de Desenvolvimento
As Dev Notes contem contexto tecnico essencial para implementacao. O objetivo e que o desenvolvedor (humano ou IA) nao precise ler o documento de arquitetura inteiro - as notas resumem o necessario para aquela story especifica.
O que incluir nas Dev Notes
- • src/services/auth.ts
- • src/components/LoginForm.tsx
- • src/hooks/useAuth.ts
- • Usar React Hook Form
- • Validacao com Zod
- • Tokens JWT no localStorage
- • STORY-000: Setup Auth Context
- • API endpoint ja existe
- • Rate limit: 5 tentativas/min
- • Nao logar senhas
✨ Dica para IAs
Para agentes de IA, inclua tambem: exemplos de codigo similares no projeto, links para documentacao de bibliotecas usadas, e qualquer decisao arquitetural relevante.
🤖 Dev Agent Record
Quando uma IA implementa a story, o Dev Agent Record registra tudo que aconteceu. Isso garante auditabilidade total - voce sabe exatamente qual modelo fez o que, quando, e quais decisoes tomou.
Campos do Dev Agent Record
Exemplo de Dev Agent Record
Session: cc-2024-01-15-abc123
Started: 2024-01-15 14:30:00
Completed: 2024-01-15 14:45:22
Files Modified:
- src/services/auth.ts (created)
- src/components/LoginForm.tsx (created)
- src/hooks/useAuth.ts (modified)
Debug Log:
- TypeScript error on line 45: fixed import
- Added missing Zod schema validation
Notes:
All ACs implemented. Ready for QA review.
🧪 QA Results
A secao QA Results documenta a validacao final da story. Uma story so pode ser considerada DONE quando o QA aprova. Isso inclui checklist de validacao, bugs encontrados, e aprovacao formal.
Checklist de QA
🐛 Bugs Encontrados
Lista de bugs e se foram corrigidos:
✅ Aprovacao Final
🤖 Stories para IA
Stories destinadas a agentes de IA precisam ser mais detalhadas do que para humanos. A IA nao tem contexto implicito - ela nao sabe o que "faz sentido" no seu projeto. Tudo deve ser explicito.
O que adicionar para IAs
Indique exatamente onde cada arquivo deve ser criado
Mostre padroes existentes no projeto para a IA seguir
Links para docs de bibliotecas que serao usadas
Liste anti-patterns e restricoes explicitas
Comparacao: Story para Humano vs IA
"Criar form de login seguindo o padrao do projeto"
"Criar src/components/LoginForm.tsx usando React Hook Form + Zod. Seguir padrao de src/components/RegisterForm.tsx. Usar cores do Design System em src/styles/tokens.ts. Nao usar CSS inline."
📏 Tamanho Ideal de uma Story
Uma story deve ser completavel em uma sessao de trabalho - tipicamente entre 2 e 4 horas. Se for maior, quebre em stories menores. Stories muito grandes sao dificeis de estimar, revisar e testar.
Regra do INVEST
❌ Story muito grande
"Implementar sistema de autenticacao completo"
Problema: Muitas funcionalidades, impossivel estimar
✅ Stories corretas
- • STORY-001: User Login
- • STORY-002: User Registration
- • STORY-003: Password Reset
- • STORY-004: Session Management
📋 Resumo: User Stories no GIPM
Baixe o template e comece a usar em seus projetos!
⬇️ Download Template