Estimativa é um dos temas mais debatidos nas comunidades Agile. Os debates geralmente vão assim: Story Points versus horas, dimensionamento relativo versus absoluto, #NoEstimates versus algumas estimativas, planning poker versus o que veio depois.
Esses são debates reais. E eles tendem a perder o problema mais profundo — que os argumentos sobre como estimar estão substituindo uma conversa sobre se o modelo de estimativa em si é o problema.
O que Agile realmente disse sobre estimativa
Agile não surgiu para ajudar equipes a estimar melhor. Surgiu porque alguém percebeu que no trabalho complexo — trabalho onde os requisitos completos não podem ser conhecidos antecipadamente, onde a abordagem correta se revela através da prática — a precisão que a estimativa promete é falsa precisão.
O que realmente significa “trabalho complexo”
Essa expressão — trabalho complexo, trabalho onde os requisitos completos não podem ser conhecidos antecipadamente — é fácil de passar por cima. Não deveria ser. É a afirmação mais estrutural deste artigo, e sem internalizá-la, tudo que se segue pode ser ouvido como um argumento sobre técnicas de estimativa em vez de sobre a adequação da estimativa para o propósito.
Trabalho complexo não é uma descrição de projetos onde a equipe não era inteligente o suficiente, ou rigorosa o suficiente, ou onde a metodologia certa ainda não havia sido aplicada. Nomeia uma categoria específica: trabalho onde a relação entre causa e efeito só pode ser entendida em retrospecto. Onde a abordagem correta se revela através da prática, não da análise. Onde os requisitos mudam não porque as partes interessadas não pensaram cuidadosamente com antecedência, mas porque fazer o trabalho muda o que é necessário.
Metodologias — mesmo excelentes — são construídas para trabalho simples e complicado. Operam aplicando padrões conhecidos a tipos de problemas conhecidos. Esse é precisamente o seu valor nos contextos para os quais foram projetadas. O trabalho complexo não tem padrões conhecidos. Tem padrões emergentes. Aplicar uma metodologia ao trabalho complexo não resolve o problema — cria a ilusão de estrutura enquanto a incerteza real permanece intocada. As mini-cascatas — o planejamento sequencial de ciclo curto em que muitas implementações Agile silenciosamente se tornaram — caem na mesma categoria. A duração da iteração muda; o pressuposto subjacente de que o planejamento antecipado pode guiar de forma confiável o trabalho não muda.
“Simplificação implacável” é uma prescrição relacionada que vale examinar. Se o trabalho pode genuinamente ser simplificado a um tipo de problema conhecido, simplifique-o — é uma boa prática. Mas é higiene, não gestão de trabalho complexo. O que resta após toda simplificação possível é a parte que resiste a ela, que é o próprio trabalho complexo, exigindo algo que as estratégias de simplificação não foram projetadas para fornecer. Em 2025, se a resposta competitiva à complexidade é “devemos simplificar mais”, a conversa sobre gerenciar realmente o trabalho complexo ainda não começou.
A reversão pública de Jeffries não é apenas uma mudança de opinião sobre uma unidade de medida. É o reconhecimento de algo mais profundo: a premissa estava errada. A estimativa assume uma categoria de trabalho onde a análise antecipada produz previsões confiáveis. Para trabalho simples e complicado, esse pressuposto se sustenta razoavelmente bem. Para trabalho complexo, não se sustenta — e nenhum refinamento da técnica o fará. Essa percepção, uma vez internalizada, muda do que trata o resto deste artigo.
Um sprint de duas semanas entregando software funcionando não é um método de estimativa melhor. É uma substituição da estimativa por medição empírica. Em vez de prever quanto tempo o trabalho levará, você mede quanto é realmente realizado, sob condições reais, em incrementos reais. A previsão é substituída por uma cadência e um ciclo de feedback.
Esta não é uma distinção sutil. Significa que equipes que executam processos Agile mas ainda tratam a estimativa precisa de Story Points como objetivo entenderam fundamentalmente errado para que serve o processo.
Por que os argumentos persistem
O debate sobre estimativa persiste em parte porque as organizações que adotaram Agile não abandonaram sua necessidade subjacente: sistemas de gestão construídos em previsões, orçamentos, prazos, contratos. As cerimônias Agile foram sobrepostas a essa necessidade. Os Story Points se tornaram substitutos para horas. Velocity se tornou um insumo de planejamento. O vocabulário Agile foi adotado; a expectativa de previsão não foi descartada.
A situação resultante é genuinamente contestada. Algumas equipes operam em ambientes onde “sem estimativas” é genuinamente possível — onde as partes interessadas aprenderam a confiar na entrega empírica e não precisam de previsões. Outras equipes operam em ambientes onde contratos, requisitos regulatórios ou cultura organizacional tornam alguma forma de previsão inevitável.
A posição Agile não é que estimativa é sempre errada. É que estimativa em trabalho complexo é estruturalmente pouco confiável — que a confiança associada às estimativas regularmente excede as evidências para elas — e que a disciplina de ciclos de entrega curtos com feedback real faz mais para melhorar a previsibilidade do que melhores métodos de estimativa.
O problema das unidades — e um padrão que vale notar
Uma tendência atual nos círculos Agile é afastar-se dos Story Points em direção aos Dias Ideais (IPDs) — um retorno à estimativa baseada em tempo que seus proponentes argumentam ser mais intuitiva e mais fácil de defender para as partes interessadas.
Vale a pena saber de onde vieram os Story Points. Ron Jeffries — um dos três fundadores do Extreme Programming e signatário original do Manifesto Agile — inventou os Story Points. Surgiram diretamente dos dias ideais, a unidade baseada em tempo que equipes XP originalmente usavam. O problema com os dias ideais era que as partes interessadas ouviam “três dias ideais” e interpretavam isso como um compromisso de três dias, independentemente do qualificador “ideal”. Então o rótulo de tempo foi removido, e o número bruto se tornou a unidade. Os Story Points eram, em origem, dias ideais com a referência temporal removida especificamente para evitar que fossem tratados como compromissos de tempo.
Jeffries escreveu sobre isso diretamente desde então. “Gosto de dizer que posso ter inventado os Story Points”, escreveu em 2019, “e se o fiz, lamento agora.” Ele está agora entre os defensores mais proeminentes de #NoEstimates — a posição de que o problema não é qual unidade de estimativa você usa, mas que a estimativa em trabalho complexo é fundamentalmente pouco confiável independentemente da unidade.
Vale a pena perguntar por que a mudança para IPDs está acontecendo agora. A resposta não é que as equipes encontraram um método de estimativa melhor. É que os IPDs se alinham com a infraestrutura financeira do Waterfall — os ciclos orçamentários, os sistemas de contabilidade de projetos, os modelos de faturamento de contratos e as ferramentas de planejamento de pessoal que as organizações construíram em torno do planejamento baseado em tempo e nunca mudaram quando adotaram Agile. Os Story Points não se encaixam nesses sistemas. Os IPDs se encaixam.
Isso não é uma evolução do Agile. É o Waterfall continuando a se reafirmar com as roupas do Agile — usando as estruturas financeiras que nunca foram desmanteladas para puxar a prática de volta em direção ao modelo para o qual essas estruturas foram construídas. A unidade de estimativa mudou; o sistema organizacional exigindo compromissos baseados em tempo não mudou. O resultado é o mesmo teatro de previsão, apenas com um novo nome.
Isso não são empresas finalmente assumindo o controle e corrigindo o que Agile perdeu. São empresas reafirmando a infraestrutura que nunca mudou. Os IPDs não requerem nenhuma mudança de mente, compreensão ou pensamento — você simplesmente rerotula o que já sabe. É precisamente por isso que estão ganhando terreno.
A comunidade Agile perdeu uma oportunidade de liderança aqui. Quando a demanda por previsões baseadas em tempo retornou disfarçada de IPDs, a resposta correta era nomear o que estava acontecendo: este é o financiamento Waterfall se reafirmando sobre a prática Agile. Em vez disso, muitos praticantes acomodaram-no, tratando a demanda como uma restrição a gerenciar em vez de um erro de categoria a corrigir. O resultado é que as equipes mais fluentes no vocabulário Agile frequentemente executam a versão mais sofisticada do modelo que Agile foi projetado para substituir.
A humanidade aprende devagar
Há um padrão aqui que vai mais fundo do que a metodologia de estimativa. É o padrão de tratar uma mudança de rótulo como uma mudança de prática — de confundir a adoção de novo vocabulário com a mudança de pensamento que esse vocabulário deveria representar.
A definição de insanidade de Einstein é frequentemente citada, geralmente mal atribuída, mas confiavelmente ressonante: fazer a mesma coisa repetidamente e esperar resultados diferentes. A atribuição é provavelmente apócrifa. O padrão não é. Organizações que adotaram cerimônias Agile sem adotar o pensamento Agile estão agora adotando as cerimônias substitutivas do Agile sem examinar se o pensamento subjacente mudou. As palavras são diferentes. O modelo é o mesmo.
A conversa que este artigo tenta abrir não é sobre unidades de estimativa. É sobre se sua organização genuinamente considerou o que é trabalho complexo e o que ele exige. Se a resposta é que sua infraestrutura de planejamento não mudou — que você ainda precisa de previsões, compromissos e contabilidade baseada em tempo que assumem que a análise antecipada produz previsões confiáveis — então o debate sobre estimativa é um sintoma. A condição que ele aponta é que a mudança que Agile estava propondo ainda não aconteceu.
Comentários 0