Para Que Serve a Estimativa

A estimativa cumpre três propósitos, e equipes que os confundem acabam frustradas com os três.

Propósito 1: Entendimento compartilhado. Quando uma equipe estima um ticket em conjunto, o número é um efeito colateral. O resultado real é a conversa. Um desenvolvedor diz "é uma mudança pequena — trocar o endpoint e atualizar os testes." Outro diz "espera, esse endpoint está atrás de uma feature flag da qual três outros serviços dependem." A diferença entre suas estimativas é a diferença entre seus modelos mentais do trabalho. Expor essa diferença antes do trabalho começar vale mais do que o número jamais valerá.

Propósito 2: Planejamento de capacidade. Uma equipe com 10 desenvolvedores e um sprint de duas semanas tem uma quantidade finita de trabalho que pode absorver. A estimativa — mesmo aproximada — indica se você está carregando 80% da capacidade ou 140%. Sem ela, o planejamento do sprint é adivinhação, e "nos comprometemos com muito" se torna um tema recorrente nas retrospectivas.

Propósito 3: Priorização. Uma funcionalidade que entrega valor moderado e custa um esforço pequeno é uma conversa diferente de uma funcionalidade que entrega o mesmo valor e custa um esforço grande. A estimativa dá ao produto e à engenharia uma linguagem compartilhada para fazer trade-offs. Sem ela, a priorização fica com quem argumenta mais alto.

Alguns trabalhos genuinamente não podem ser estimados, e fingir o contrário produz números que enganam mais do que informam.

Um ticket que diz "investigar por que o webhook de pagamento falha intermitentemente" não é estimável. O desenvolvedor não sabe se a causa raiz é uma condição de corrida, um timeout de API de terceiros, uma política de retry mal configurada ou algo completamente diferente. Estimá-lo como "médio" apenas atribui um número à ignorância — e agora o plano do sprint trata esse número como se significasse algo.

A resposta honesta é "não sei, e preciso de um spike para descobrir." Um spike é uma investigação com tempo limitado — tipicamente meio dia a dois dias — cuja saída não é código funcionando, mas informação. Após o spike, a equipe sabe o suficiente para estimar a correção real. Spikes não são uma falha da estimativa; são a estimativa funcionando corretamente ao admitir seus próprios limites.

O mesmo se aplica a trabalhos genuinamente novos: uma nova integração com uma API desconhecida, uma migração para uma tecnologia que a equipe não usou, ou um problema de desempenho sem gargalo óbvio. Forçar uma estimativa nesses tickets não produz informação útil — produz um número que a equipe se sente obrigada a atingir e um plano construído sobre ficção.

Equipes que se obsessam com a precisão da estimativa estão otimizando a coisa errada. Uma equipe cujas estimativas consistentemente erram por 30% mas que usa a conversa de estimativa para expor premissas, capturar lacunas de escopo e alinhar a abordagem está obtendo mais valor da estimativa do que uma equipe cujos números acertam perfeitamente mas que estima em silêncio.

O número é um subproduto. A conversa é o produto. Quando dois desenvolvedores estimam o mesmo ticket de forma diferente, esse desacordo é informação — um deles sabe algo que o outro não sabe, ou estão imaginando implementações diferentes. Resolver esse desacordo antes do trabalho começar previne retrabalho, captura requisitos faltantes e constrói contexto compartilhado na equipe.

É por isso que métodos de estimativa que forçam a conversa (como /learn/xp/planning-practices/planning-game, onde todos revelam simultaneamente) superam métodos que não forçam (como uma pessoa anunciar um número e perguntar "isso parece certo?"). A revelação não é sobre o número — é sobre a diferença. Um ticket onde todos mostram um 3 é entediante. Um ticket onde uma pessoa mostra um 2 e outra mostra um 8 é onde a estimativa se paga.