Release Planning com Planning Poker
Estimar um sprint é uma coisa. Estimar uma release inteira com 50+ itens é outra. Mas com as técnicas certas, o Planning Poker escala para planejamento de releases também.
O desafio do release planning
- Muitos itens: 50-200 histórias para estimar
- Menos detalhes: itens de release muitas vezes não estão refinados
- Horizonte longo: 2-6 meses de incerteza
- Stakeholders impatientes: querem uma data”
Estratégia de estimativa em camadas
Nível 1: Épicos (T-Shirt sizing)
Estime os grandes blocos de trabalho com tamanhos de camiseta:
- Épico “Checkout”: XL
- Épico “Catálogo”: L
- Épico “Notificações”: M
Isso dá uma visão macro em 30-60 minutos.
Nível 2: Features (Planning Poker com escala ampliada)
Para cada épico, estime as features com valores ampliados:
| Feature | Pontos |
|---|---|
| Checkout com cartão | 13 |
| Checkout com PIX | 8 |
| Cupom de desconto | 5 |
| Subtotal Checkout | 26 |
Nível 3: Stories (Planning Poker normal)
Para as features do próximo sprint, estime normalmente com Fibonacci (0.5-13).
Calculando a release
Fórmula
Total de pontos da release = soma de todos os itens estimados
Número de sprints = total de pontos / velocidade média do time
Data estimada = sprint atual + número de sprints calculadoExemplo prático
| Épico | Pontos |
|---|---|
| Checkout | 26 |
| Catálogo | 18 |
| Notificações | 13 |
| Relatórios | 8 |
| Performance | 5 |
| Total | 70 |
Velocidade média: 25 pontos/sprint Sprints necessários: 70/25 = ~3 sprints Com sprints de 2 semanas: ~6 semanas
Adicionando buffer de incerteza
Para releases longas, adicione buffer:
- Release de 1-2 meses: +15% de buffer
- Release de 3-4 meses: +25% de buffer
- Release de 5+ meses: +40% de buffer
No exemplo acima (3 sprints): 70 + 25% = ~88 pontos → ~3.5 sprints → 7 semanas.
Lidando com incerteza nos itens
Classifique por confiança
- Alta confiança: itens já refinados → estimativa precisa
- Média confiança: itens com descrição mas sem detalhamento → estimativa com ±30%
- Baixa confiança: épicos vague — estimativa com ±50%
Use range de datas
Ruim: “A release fica pronta em 12 de agosto.” Bom: “A release fica pronta entre 5 e 19 de agosto, com mais probabilidade para a segunda semana.”
Revise a cada sprint
A cada sprint, recalcule:
- Pontos entregues vs. planejados
- Velocidade atualizada
- Data estimada revisada
Stakeholders devem ver essa atualização semanalmente.
Release Planning multi-time
Quando múltiplos squads contribuem para uma release:
- Estime por time — cada squad estima seu escopo
- Mapele dependências — quem depende de quem
- Some as velocidades — velocidade combinada dos times
- Identifique o caminho crítico — a dependência mais lenta dita o timeline
Exemplo
| Squad | Pontos | Velocidade | Sprints |
|---|---|---|---|
| Squad A (Checkout) | 30 | 25/sprint | 1.2 |
| Squad B (Backend) | 20 | 20/sprint | 1.0 |
| Squad C (Mobile) | 15 | 15/sprint | 1.0 |
Mas se Squad C depende de Squad B, e Squad B depende de Squad A:
- Sprint 1: Squad A
- Sprint 2: Squad B
- Sprint 3: Squad C
- Total: 3 sprints (não 1.2)
Dependencies matter!
Ferramentas para Release Planning
- Jira Advanced Roadmaps: timeline visual com dependências
- Dev in Poker: estimativa rápida de muitos itens
- Miro/FigJam: mapeamento visual de épico e dependências
- Planilhas: funcional para cálculos simples
Conclusão
Release Planning com Planning Poker é viável e eficiente quando feito em camadas: T-Shirt para épicos, Planning Poker para features, e detalhamento progressivo conforme a release se aproxima. Comunique ranges, não datas fixas, e revise a cada sprint.