Épicos, features e stories: como quebrar trabalho

“Como administrador, quero um sistema completo de relatórios” — isso não cabe em um sprint. Precisa ser quebrado. Mas como quebrar de forma eficiente sem perder o contexto do valor entregue?

A hierarquia do trabalho

ÉPICO (meses)
  └── FEATURE (sprints)
        └── USER STORY (dias)
              └── TAREFA (horas)

Épico

Grande iniciativa de produto. Leva meses para ser completa.

“Programa de fidelidade completo”

Feature

Funcionalidade específica dentro do épico. Pode levar 1-3 sprints.

“Sistema de pontos de fidelidade”

User Story

Entrega de valor para o usuário. Cabe em um sprint (idealmente em alguns dias).

“Como cliente, quero ver meu saldo de pontos na página da minha conta.”

Tarefa

Passo técnico para implementar a história. Medida em horas.

“Criar endpoint GET /users/:id/points”

Técnicas de decomposição

1. Por fluxo de trabalho

Divida cada etapa do processo do usuário:

• Cadastro → Login → Busca → Carrinho → Checkout → Pagamento

Épico: “Checkout”

• Stories: endereço, frete, pagamento, confirmação, cupom

2. Por regra de negócio

Variações de regras dentro de uma funcionalidade:

• Pagamento com cartão
• Pagamento com boleto
• Pagamento com PIX
• Pagamento com saldo de pontos

3. Por tipo de usuário

Diferentes personas têm necessidades diferentes:

Épico: “Dashboard”

• Stories: dashboard do cliente, dashboard do vendedor, dashboard do admin

4. Vertical vs Horizontal

Decomposição vertical (recomendada): Cada história entrega ponta a ponta: UI + API + Banco

Story 1: “Como cliente, quero pagar com cartão” → UI do cartão (frontend) + processamento (backend) + registro (banco)

Decomposição horizontal (evitar): Camadas separadas: “Criar todas as APIs”, “Criar todo o frontend”

Problema: não há valor entregue até tudo estar pronto.

Critérios para saber que quebrou o suficiente

Uma história está bem decomposta quando:

• Cabe confortavelmente em um sprint (máx. 5-8 pontos)
• Tem critérios de aceitação claros
• Entregue valor independente
• O time consegue estimar com confiança

Anti-padrões comuns

A micro-história

“Como usuário, quero que o botão seja azul.” — Isso é um detalhe de design, não uma história.

A história infinita

“Como admin, quero gerenciar tudo.” — Isso é um épico disfarçado de história. Se a estimativa fica em 21 ou ?, está grande demais.

Dependência circular

Story A precisa da B que precisa da A. Isso indica que a decomposição não respeitou independência.

Estimativa por nível

• Épico: T-Shirt sizing (S, M, L, XL) — estimativa grosseira para roadmap
• Feature: Planning Poker com valores altos (13, 20, 40) — ainda com margem
• Story: Planning Poker com precisão (0.5, 1, 2, 3, 5, 8, 13) — escala padrão
• Tarefa: Horas — para o dia a dia do desenvolvedor

Conclusão

Bons histórias são o resultado da decomposição inteligente de épicos grandes. A chave é quebrar por valor entregue ao usuário, não por camadas técnicas. Cada história deve ser independente, testável e entregar algo útil por si só.