7 min leitura • Guide 791 of 877
Técnicas de Divisão de User Stories
Stories grandes são arriscadas e difíceis de estimar. O GitScrum ajuda equipes a rastrear stories divididas mantendo conexão com o épico original.
Por Que Dividir Stories
Benefícios de Stories Pequenas
BENEFÍCIOS DE STORIES PEQUENAS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ RISCOS DE STORY GRANDE: │
│ ────────────────────── │
│ ❌ Difícil de estimar com precisão │
│ ❌ Pode não caber no sprint │
│ ❌ Ciclos longos de feedback │
│ ❌ Alto risco de retrabalho │
│ ❌ Progresso bloqueado │
│ ❌ Síndrome do "90% pronto" │
│ │
│ BENEFÍCIOS DE STORY PEQUENA: │
│ ─────────────────────────── │
│ ✅ Mais fácil de estimar │
│ ✅ Cabe no sprint │
│ ✅ Feedback rápido │
│ ✅ Menor risco │
│ ✅ Progresso visível │
│ ✅ Done é done │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ GUIA DE TAMANHO: │
│ │
│ MUITO GRANDE (13+ pontos): │
│ • Mais que metade do sprint │
│ • Divisão obrigatória │
│ │
│ LIMÍTROFE (8 pontos): │
│ • Considere dividir │
│ • Depende da complexidade │
│ │
│ BOM TAMANHO (1-5 pontos): │
│ • Completa em 1-3 dias │
│ • Cabe bem no sprint │
│ │
│ MUITO PEQUENA (1 ponto): │
│ • Overhead de tracking custa mais que trabalho │
│ • Combine com trabalho relacionado │
└─────────────────────────────────────────────────────────────┘
Padrões de Divisão
Por Etapas do Workflow
DIVIDINDO POR WORKFLOW:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PADRÃO: Operações CRUD │
│ │
│ ORIGINAL (21 pontos): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Como admin, quero gerenciar usuários para que ││
│ │ eu possa controlar acesso ao sistema. ││
│ │ ││
│ │ Inclui: ││
│ │ • Criar usuários ││
│ │ • Listar usuários ││
│ │ • Editar usuários ││
│ │ • Deletar usuários ││
│ │ • Atribuir roles ││
│ │ • Buscar/filtrar ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ DIVIDIDA: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 1. Ver lista de usuários (3 pts) ││
│ │ Lista básica com nome, email, status ││
│ │ ││
│ │ 2. Criar novo usuário (5 pts) ││
│ │ Formulário com validação, notificação email ││
│ │ ││
│ │ 3. Editar detalhes do usuário (3 pts) ││
│ │ Atualizar nome, email, status ││
│ │ ││
│ │ 4. Deletar/desativar usuário (3 pts) ││
│ │ Soft delete com confirmação ││
│ │ ││
│ │ 5. Atribuir roles ao usuário (5 pts) ││
│ │ Seletor de role, display de permissões ││
│ │ ││
│ │ 6. Buscar e filtrar usuários (3 pts) ││
│ │ Por nome, email, role, status ││
│ │ ││
│ │ Total: 22 pts (em 6 stories menores) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ Cada story entrega valor independentemente │
│ Pode entregar após story 1-2 │
└─────────────────────────────────────────────────────────────┘
Por Tipo de Usuário
DIVIDINDO POR PERSONA:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PADRÃO: Usuários Diferentes, Necessidades Diferentes │
│ │
│ ORIGINAL (13 pontos): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Como usuário, quero um dashboard para que eu possa ││
│ │ ver métricas e ações relevantes. ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ PROBLEMA: "usuário" é muito genérico │
│ │
│ DIVIDIDA: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 1. Dashboard do Desenvolvedor (5 pts) ││
│ │ Ver minhas tarefas, PRs pendentes, bloqueios ││
│ │ ││
│ │ 2. Dashboard do Gerente de Projeto (5 pts) ││
│ │ Ver progresso do sprint, velocity, riscos ││
│ │ ││
│ │ 3. Dashboard do Stakeholder (3 pts) ││
│ │ Ver status de alto nível, marcos, datas ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ Cada persona tem necessidades específicas │
│ Pode priorizar por persona mais importante │
└─────────────────────────────────────────────────────────────┘
Por Regras de Negócio
DIVIDINDO POR REGRAS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PADRÃO: Happy Path Primeiro, Depois Edge Cases │
│ │
│ ORIGINAL (13 pontos): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Como cliente, quero aplicar cupom de desconto no ││
│ │ checkout para economizar na compra. ││
│ │ ││
│ │ Regras: ││
│ │ • Cupom válido aplica desconto ││
│ │ • Cupom expirado mostra erro ││
│ │ • Um cupom por pedido ││
│ │ • Cupom não acumula com promoção ││
│ │ • Valor mínimo para alguns cupons ││
│ │ • Cupons limitados por uso ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ DIVIDIDA: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 1. Aplicar cupom válido (3 pts) ││
│ │ Happy path - cupom funciona ││
│ │ ││
│ │ 2. Validar cupom expirado (2 pts) ││
│ │ Mostrar mensagem de erro clara ││
│ │ ││
│ │ 3. Limitar um cupom por pedido (2 pts) ││
│ │ Trocar cupom se já tiver um ││
│ │ ││
│ │ 4. Não acumular com promoção (2 pts) ││
│ │ Escolher melhor desconto ││
│ │ ││
│ │ 5. Valor mínimo para cupons (2 pts) ││
│ │ Mostrar quanto falta ││
│ │ ││
│ │ 6. Limitar uso de cupons (2 pts) ││
│ │ Contador de uso, expirar quando acabar ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ Happy path primeiro = valor entregue rápido │
│ Edge cases incrementalmente │
└─────────────────────────────────────────────────────────────┘
Por Variação de Dados
DIVIDINDO POR DADOS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PADRÃO: Um Tipo de Dado por Vez │
│ │
│ ORIGINAL (8 pontos): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Como gerente, quero exportar relatórios em múltiplos ││
│ │ formatos para compartilhar com diferentes audiências. ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ DIVIDIDA: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 1. Exportar para CSV (3 pts) ││
│ │ Formato mais pedido primeiro ││
│ │ ││
│ │ 2. Exportar para PDF (3 pts) ││
│ │ Com formatação bonita ││
│ │ ││
│ │ 3. Exportar para Excel (2 pts) ││
│ │ Com fórmulas básicas ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ Cada formato é independente │
│ Priorize o mais pedido primeiro │
└─────────────────────────────────────────────────────────────┘
Mantendo Valor
Cada Slice Entrega Valor
VERIFICAÇÃO DE VALOR:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CADA STORY DIVIDIDA DEVE: │
│ │
│ ✅ Entregar valor ao usuário sozinha │
│ (mesmo que pequeno) │
│ │
│ ✅ Ser testável independentemente │
│ (QA pode verificar) │
│ │
│ ✅ Poder ser lançada para produção │
│ (não quebra nada) │
│ │
│ ✅ Ter definição clara de done │
│ (sabe-se quando terminou) │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ DIVISÕES RUINS (não faça): │
│ │
│ ❌ Por camada técnica │
│ "Story 1: Backend" / "Story 2: Frontend" │
│ → Nenhuma entrega valor sozinha │
│ │
│ ❌ Arbitrariamente │
│ "Story 1: Primeira metade" / "Story 2: Segunda metade"│
│ → Não faz sentido │
│ │
│ ❌ Muito pequena │
│ "Story 1: Adicionar botão" / "Story 2: Conectar API" │
│ → Overhead maior que valor │
└─────────────────────────────────────────────────────────────┘