Como escalar estimativas em ambientes multi-times
Quando você tem 5 squads com 5 velocidades diferentes, 5 escalas de pontos e 5 Product Owners, planejar uma release coordenada é um desafio matemático e organizacional.
O problema fundamental
Cada squad calibra seus pontos de forma independente:
- Squad A: 1 ponto = mudança de label
- Squad B: 1 ponto = CRUD simples
- Squad C: 1 ponto = refatoração pequena
Os pontos não são comparáveis. E isso é ok.
Estratégia 1: Não normalize pontos
Em vez de tentar normalizar pontos entre squads:
- Planeje por squad: cada squad entrega X pontos/sprint
- Some entregas, não pontos: “Squad A entrega checkout, Squad B entrega catálogo”
- Use T-Shirt sizing épicos cross-squad para planejamento macro
Estratégia 2: Normalização por referência (quando necessário)
Se precisa comparar:
- Escolha um item de referência comum a todos os squads
- Cada squad estima esse item
- Calcule fator de normalização:
Squad A estima referência = 3 pontos → fator 1.0
Squad B estima referência = 5 pontos → fator 0.6
Squad C estima referência = 8 pontos → fator 0.375
Aplique o fator às velocidades de cada squad para comparar.
Estratégia 3: Release planning com dependências
Quando squads dependem uns dos outros:
-
Mapeamento de dependências:
- Quem precisa de quem?
- Qual a ordem lógica?
-
Estime cada squad independentemente.
-
Calcule o caminho crítico:
- Squad A (checkout): 2 sprints
- Squad B (frontend checkout): 1 sprint (depende de A)
- Squad C (integração): 1 sprint (depende de B)
- Total: 4 sprints sequenciais, não 2 paralelos
Estratégia 4: Planning conjunto para features cross-squad
Para features que envolvem múltiplos squads:
Big Room Planning (ou PI Planning)
- Todos os squads na mesma sala (física ou virtual)
- Visão do produto apresentada pelo Product Management
- Cada squad faz seu Planning para as features atribuídas
- Dependencies mapeadas em um board visual
- Riscos identificados e mitigados
Duração
- 1 dia para 3-5 squads
- 2 dias para 6-10 squads
Output
- Plano de entrega por squad
- Dependências visualizadas
- Riscos e mitigações
- Timeline consolidado
Métricas consolidadas
| Métrica | Como consolidar |
|---|---|
| Velocidade total | Some entregas (não pontos). “5 squads entregaram 18 features.” |
| Lead time | Medir por feature, não por squad. |
| Delivery rate | % de features entregues por todos os squads vs. planejado |
| Qualidade | Bugs em produção combinados de todos os squads |
Anti-padrões de escala
Comparar velocity entre squads
“Squad A entregou 30 pontos, Squad B 20. Squad A é melhor.” Erro — escalas diferentes.
Forçar mesma escala de pontos
“Todos os squads devem calibrar seus pontos da mesma forma.” Impossível e contraproducente. Perde-se a calibração local.
Centralizar estimativas
“O arquiteto estima para todos os squads.” Elimina a autonomia e a precisão de quem conhece o código.
Conclusão
Escalar estimativas não é normalizar — é coordenar. Respeite a autonomia de cada squad, mapele dependências explicitamente e use planning conjunto para features cross-squad. A matemática é simples: dependencies determinam o timeline, não os pontos.