← Voltar ao blog

Como escalar estimativas em ambientes multi-times

estimativas multi-times agile-at-scale

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:

  1. Escolha um item de referência comum a todos os squads
  2. Cada squad estima esse item
  3. 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:

  1. Mapeamento de dependências:

    • Quem precisa de quem?
    • Qual a ordem lógica?
  2. Estime cada squad independentemente.

  3. 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)

  1. Todos os squads na mesma sala (física ou virtual)
  2. Visão do produto apresentada pelo Product Management
  3. Cada squad faz seu Planning para as features atribuídas
  4. Dependencies mapeadas em um board visual
  5. 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étricaComo consolidar
Velocidade totalSome entregas (não pontos). “5 squads entregaram 18 features.”
Lead timeMedir por feature, não por squad.
Delivery rate% de features entregues por todos os squads vs. planejado
QualidadeBugs 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.