O Que a Estimativa Não Te Dá

Uma estimativa é uma previsão, não um contrato. No momento em que um equipo trata uma estimativa como um compromisso — "você disse que era um 5, então deveria estar pronto na quarta-feira" — a estimativa deixa de ser uma ferramenta de planejamento e se torna um mecanismo de punição. Os engenheiros respondem inflando as estimativas para se proteger, o que torna as estimativas inúteis para o planejamento, o que faz os stakeholders pressionarem mais por números "precisos", o que faz os engenheiros inflarem ainda mais. O ciclo é previsível e comum.

A distinção importa mais na fronteira entre engenharia e o resto da organização. Dentro do equipo, as estimativas orientam a capacidade do sprint e ajudam a identificar semanas sobrecarregadas. Isso é bom — o equipo controla o plano e pode ajustar no meio do sprint. O problema começa quando as estimativas saem do equipo como promessas de entrega para vendas, executivos ou clientes. Um "achamos que isso é cerca de 13 pontos de trabalho" se torna "engenharia se comprometeu com três semanas" em uma apresentação que o equipo nunca vê.

Proteger as estimativas de se tornarem compromissos é uma disciplina do equipo e uma responsabilidade da liderança. O equipo deve comunicar estimativas como faixas ("2–4 semanas dependendo do que encontrarmos no código legado"), não pontos. E os líderes devem resistir à pressão de remover a incerteza das estimativas para fazer um roadmap parecer mais limpo. A incerteza é a parte honesta.

A estimativa tem um custo: o tempo que o equipo gasta estimando em vez de construir. Para a maioria dos equipos, esse custo é razoável — 30 minutos de estimativa economizam horas de surpresas no meio do sprint. Mas o custo pode crescer até que a cerimônia consuma mais valor do que produz.

Sinais de alerta de que a estimativa se tornou seu próprio desperdício:

• Sessões de estimativa duram mais de uma hora. Se o equipo está gastando 90 minutos estimando o trabalho de um sprint, os tickets não estão bem definidos o suficiente para estimar, ou o equipo está debatendo detalhes de implementação que pertencem a discussões de design, não de estimativa.
• Ninguém usa as estimativas depois da sessão. Se as estimativas vão para o rastreador e ninguém as referencia durante o planejamento do sprint, verificações de capacidade ou retrospectivas, o equipo está produzindo números para ninguém. Pare de estimar esses tickets e gaste o tempo em outro lugar.
• Re-estimativa é rotina. Se o equipo regularmente re-estima tickets porque o escopo mudou, os requisitos mudaram ou "entendemos melhor agora", a estimativa está acontecendo cedo demais. Estime mais tarde, quando o trabalho estiver melhor definido, ou aceite que estimativas iniciais são aproximadas e não re-estime.

O princípio é o mesmo que se aplica a cada parte do processo: se não está criando alavancagem, está criando sobrecarga. A estimativa deve ser barata, rápida e útil. Quando se torna cara, lenta ou ignorada, reduza a escala.

O movimento #NoEstimates argumenta que a estimativa é frequentemente desnecessária e que os equipos podem prever a entrega usando throughput histórico — o número de tickets concluídos por semana — em vez de atribuir tamanhos a tickets individuais. O argumento tem mérito, e descartá-lo como preguiça é tão errado quanto tratá-lo como evangelho.

A previsão baseada em throughput funciona assim: se um equipo consistentemente completa 10–14 tickets por semana, e um projeto tem 45 tickets, a previsão é de 3–5 semanas. Nenhuma sessão de estimativa necessária. A matemática depende de duas condições: os tickets precisam ser fatiados em tamanhos aproximadamente similares, e o equipo precisa de dados históricos suficientes para estabelecer uma faixa de throughput confiável. Quando essas condições se mantêm, a previsão é frequentemente mais precisa do que uma estimativa bottom-up de cada ticket individual.

O problema é a disciplina. Equipos que pulam a estimativa mas também pulam a disciplina de fatiamento acabam sem nenhuma capacidade de previsão — eles não podem estimar porque abandonaram a prática, e não podem usar throughput porque seus tickets variam de correções de uma hora a épicos de três semanas. #NoEstimates sem fatiamento consistente é apenas #NoInformation.

Para a maioria dos equipos, o caminho pragmático está em algum lugar no meio: estime levemente (P/M/G), rastreie throughput como um sinal secundário, e abandone a estimativa completamente apenas quando os dados mostrarem que throughput sozinho é suficiente. A pior escolha é estimar pesadamente e ignorar throughput — isso é cerimônia máxima para informação mínima.