Estimativas são necessárias? O debate NoEstimates
O movimento #NoEstimates surgiu como resposta à frustração com estimativas imprecisas e o tempo gasto em sessões de planning. A ideia central é: em vez de estimar, entregue frequentemente e use dados reais para planejar.
O argumento do NoEstimates
Estimativas são desperdício
“Se entregamos uma feature por dia, por que gastar 2 horas estimando 10 features?”
Resposta: Estimativas não são para saber quanto cada feature custa individualmente. São para decidir prioridade. Uma feature de 13 pontos pode ter menos prioridade que uma de 3 pontos se o valor for similar.
Dados reais são melhores que estimativas
“Lead time histórico diz que entregamos 5 features/semana. Use isso, não story points.”
Resposta: Parcialmente correto. Lead time é excelente para prever throughput. Mas não ajuda a responder: “Essa feature grande cabe no próximo sprint?”
Estimativas criam falsa precisão
“Dizer 5 pontos dá a ilusão de que sabemos o que vai acontecer.”
Resposta: Estimativas são previsões com intervalo de confiança, não certezas. O problema não é estimar — é tratar estimativa como promessa.
Quando NoEstimates funciona
Time maduro com fluxo estável
Times que entregam consistentemente ~5 features/sprint podem simplesmente usar throughput como métrica de planejamento.
Produtos com features de tamanho similar
Se quase todas as features levam 2-3 dias, estimar individualmente tem pouco valor agregado.
Times Kanban
Kanban não requer estimativas obrigatoriamente. Lead time e throughput funcionam como métricas de planejamento.
Quando estimativas são essenciais
Features de tamanhos muito diferentes
Se uma feature leva 2 dias e outra 3 semanas, não planejar é voar às cegas.
Stakeholders precisam de previsibilidade
Executivos precisam saber se o lançamento cabe no Q3. “Entregamos 5 features/sprint” não responde se as 20 features no backlog cabem em 12 semanas.
Decisões de investimento
Priorizar entre construir X ou Y requer entender o esforço relativo de cada um.
Times novos
Sem dados históricos, estimativas são o único guia que o time tem.
Nossa posição: Right-Sizing Estimates
Não é “toda estimativa sempre” nem “nunca estime”. É estime quando o valor da informação supera o custo da estimativa.
Estime quando:
- Tarefas têm tamanhos muito diferentes
- Decisão de prioridade depende do esforço
- Stakeholders precisam de previsão de release
- Time está calibrando sua velocidade
Não estime quando:
- Tarefas são consistentemente do mesmo tamanho
- Você já tem dados suficientes de throughput
- O custo de estimar supera o valor da informação
- É uma tarefa óbvia e recorrente
O meio-termo prático
Muitos times adotam uma abordagem leve:
- Planning Poker para features grandes (> 5 pontos)
- Tamanho padrão (ex: 3 pontos) para features pequenas e similares
- Throughput para bugs e tarefas de manutenção
Conclusão
O debate NoEstimates trouxe pontos válidos: estimativas grosseiras e excessivas são desperdício. Mas a solução não é abolir estimativas — é estimar de forma inteligente, nos momentos certos, com a granularidade adequada.