Estimativas com incerteza: técnicas para o desconhecido

Nem todo item do backlog é bem compreendido. Alguns têm incerteza técnica, outros têm requisitos vagos, outros são simplesmente novos para o time. Como estimar o desconhecido?

Níveis de incerteza

Nível 1: Conhecemos o conhecido

“Já fizemos isso 5 vezes. Estimativa: 3 pontos.”

Certos. Baseados em experiência direta.

Nível 2: Conhecemos o desconhecido

“Nunca fizemos login social, mas sabemos o que é OAuth.”

Estime com analogia e adicione buffer:

• “Login local foi 3 pontos. Login social é similar mas com complexidade de provider: 5 pontos.”

Nível 3: Desconhecemos o desconhecido

“Precisamos de ML para detectar fraude. Não sabemos nada disso.”

Não estime. Crie um spike.

Técnica: Cone de Incerteza

No início de um projeto, a incerteza é enorme (±4x a ±0.25x). Conforme o time aprende, o cone se estreita.

Incerteza
  |
  |   ╱╲
  |  ╱  ╲
  | ╱    ╲
  |╱      ╲
  +━━━━━━━━━━━ Tempo
     Sprint →

Implicação: Estimativas de release no Sprint 1 devem ser ranges amplos. No Sprint 6, já são precisas.

Técnica: Estimativa Three-Point

Para cada item incerto, estime três cenários:

Cenário	Valor	Peso
Otimista (O)	3 pontos	1
Mais Provável (M)	5 pontos	4
Pessimista (P)	13 pontos	1

Estimativa = (O + 4M + P) / 6 → (3 + 4×5 + 13) / 6 = 36/6 = 6 pontos

Isso captura a assimetria da incerteza.

Técnica: Story Splitting por Risco

Para itens de alta incerteza, divida:

“Sistema de recomendação” → 21 pontos (incerto demais)

Divida em:

1. Spike: Avaliar bibliotecas de recomendação → 5 pontos (2 dias)
2. MVP: Recomendação baseada em popularidade → 8 pontos
3. Avançado: Recomendação personalizada com ML → 13 pontos

O spike reduz incerteza e as estimativas seguintes são mais precisas.

Técnica: Risk Poker

Variação do Planning Poker onde o time vota risco ao invés de esforço:

• 🟢 Baixo: temos experiência, tecnologia conhecida
• 🟡 Médio: alguma familiaridade, mas com arestas
• 🔴 Alto: tecnologia nova, domínio desconhecido

Itens 🔴 devem ter spikes antes de estimar. Itens 🟡 ganham buffer de 30-50%. Itens 🟢 são estimados normalmente.

Quando NÃO estimar

• Novo paradigma tecnológico — spike primeiro
• Requisito vago demais — PO precisa detalhar
• Dependência crítica externa — resolva a dependência primeiro
• Épico grande demais — decomponha antes de estimar

Estimativa de projetos exploratórios

Quando o produto é uma descoberta (ex: “vamos explorar se IA resolve esse problema”):

1. Timebox a exploração — “3 sprints de investigação”
2. Defina critérios de sucesso — “Se accuracy > 90%, seguimos. Se não, descartamos.”
3. Estime a exploração, não o resultado — “3 sprints × 25 pontos = 75 pontos de exploração”

Conclusão

Incerteza não é desculpa para evitar estimativas — é sinal para estimar diferente. Use técnicas como three-point, Risk Poker e spikes para transformar desconhecido em conhecido, e então estime com confiança.