Planning Fallacy: por que sempre subestimamos
Você já se perguntou por que mesmo times experientes continuam subestimando tarefas? A culpa não é só da complexidade do código — é um viés cognitivo chamado Planning Fallacy.
O que é Planning Fallacy
O Planning Fallacy é a tendência humana de subestimar o tempo necessário para completar uma tarefa, mesmo quando temos experiência com tarefas similares no passado.
Foi descrito por Daniel Kahneman e Amos Tversky em 1979. Eles mostraram que estudantes subestimavam consistentemente o tempo para completar teses — e mesmo quando cientes do viés, continuavam cometendo o erro.
Por que acontece no desenvolvimento de software
Otimismo natural
“Tarefa de integração com API — já fiz isso antes, 3 pontos!” Esquecemos que cada API tem peculiaridades: autenticação diferente, rate limit, documentação desatualizada.
Escopo invisível
Não contamos o tempo de: reuniões, code review, testes, comunicação, contexto switching, bugs inesperados, deploy. Só contamos o tempo de codificação.
Viés de confirmação
Buscamos informações que confirmam nossa estimativa e ignoramos sinais de risco: “A documentação da API parece boa” (ignorando que não há sandbox de testes).
Pressão social
Quando um stakeholder pergunta “dá pra fazer em 2 sprints?”, há um incentivo implícito para dizer sim.
Como combater o Planning Fallacy
1. Use dados históricos
Em vez de “acho que leva 5 pontos”, olhe: “dos últimos 5 itens de integração, a média foi 8 pontos”. Dados > sentimento.
2. Estimativa por three-point
Para cada tarefa, estime três cenários:
- Otimista: tudo dá certo → 3 pontos
- Mais provável: cenário realista → 5 pontos
- Pessimista: tudo que pode dar errado dá → 13 pontos
Fórmula de PERT: (Otimista + 4×MaisProvável + Pessimista) / 6
→ (3 + 4×5 + 13) / 6 = 6 pontos
3. Referência externa
Compare com projetos similares da indústria. “Times que fizeram integrações similares relataram 2-3 semanas.”
4. Pre-mortem
Antes de estimar, imagine que o sprint falhou. “Estamos no final do sprint e não entregamos. O que deu errado?” Isso força a considerar riscos que o otimismo esconde.
5. Adicione buffer
A regra dos 20%: adicione 20% à estimativa total do sprint para o inesperado. Se o time tem velocidade de 25 pontos, planeje apenas ~20.
6. Decomponha mais
Tarefas grandes são subestimadas mais frequentemente. Uma tarefa de 13 pontos, quebrada em três de 3, 5 e 3, será estimada com mais precisão.
O papel do Planning Poker
O Planning Poker é uma das melhores defesas contra o Planning Fallacy porque:
- Combina múltiplas perspectivas — cada membro tem riscos diferentes em mente
- Divergências revelam otimismo — quando alguém vota muito mais alto, geralmente vê riscos que os outros ignoraram
- Histórico força calibração — ao revisar estimativas passadas, o time percebe o padrão de subestimação
Conclusão
O Planning Fallacy não é burrice — é humano. Mas com dados, técnicas estruturadas e processos como Planning Poker, podemos mitigá-lo significativamente. O primeiro passo é reconhecer que somos naturalmente otimistas demais nas estimativas.