Por que as estimativas falham (e por que ainda são necessárias)

• Na prática de desenvolvimento de software, a estimativa de trabalho pertence ao domínio Complexo (Complex), e mesmo equipes muito experientes não conseguem fazer estimativas precisas por natureza
• O movimento #NoEstimates foi uma reação legítima ao uso indevido de estimativas como meta de desempenho, mas rejeitar a própria estimativa elimina a capacidade de coordenação da organização
• O valor central da estimativa não está em prever o futuro, e sim em comunicar e coordenar sob incerteza, sendo essencial para contratos externos, dependências entre equipes e decisões de ROI
• Segundo o Cone of Uncertainty de Steve McConnell, no início de um projeto o erro de estimativa pode chegar a um fator de 4, e a faixa só se estreita por meio de aprendizado
• É preciso mudar o hábito organizacional de transformar estimativas em promessas e adotar uma abordagem de estimativa baseada em faixas, com premissas explícitas e calibração progressiva

---

O problema que o movimento #NoEstimates realmente resolveu

• Repete-se o padrão em que se pede uma estimativa quando a equipe quase nada sabe sobre o problema, esse número entra no roadmap e acaba sendo prometido ao cliente
• Quando a realidade diverge da estimativa, a equipe é acusada de "perder o prazo", embora aquele nunca tenha sido um prazo acordado desde o início
• A patologia central é quando a estimativa deixa de ser uma previsão e vira um compromisso (commitment)
• A solução de "não vamos estimar" é como negar o próprio conceito de temperatura em reação a um termômetro quebrado
• Como disse Maarten Dalmijn, estimativas não mudam o volume real de trabalho; desenvolver uma funcionalidade leva o tempo que levar
  • O que a estimativa afeta não é o trabalho em si, mas as expectativas (expectations) ao redor dele
  • Gerenciar expectativas com honestidade e clareza é um trabalho que vale muito a pena

Por que as organizações realmente precisam de estimativas

• Um ponto quase sempre ausente no debate do #NoEstimates: estimativas não servem para a equipe que executa o trabalho, mas para a organização ao redor dela

• Há três situações inevitáveis em que estimativas são necessárias

• Compromissos externos (External commitments): em contratos com clientes, lançamentos atrelados a campanhas de marketing, prazos regulatórios etc., um modelo de duração do trabalho é essencial para avaliar viabilidade

  • "Nós não fazemos estimativas" não é uma resposta que se possa dar a um cliente, e pode levar ao fim do contrato

• Dependências entre equipes (Inter-team dependencies): se a equipe B precisa esperar a conclusão da equipe A, e a equipe A não fornece nenhuma previsão, a equipe B não consegue planejar

  • Um sinal aproximado ("talvez 6 semanas, no máximo 8") é infinitamente mais útil do que silêncio, e isso não é controle, mas respeito pelas pessoas da equipe a jusante

• Cálculo de ROI: para decidir se vale mais construir a funcionalidade X ou Y, é preciso algum modelo de custo relativo

  • Se tudo for tratado como incognoscível, não há como fazer trade-offs racionais; e se de qualquer forma vamos chutar, então é melhor um chute estruturado com premissas explícitas

O que Joseph Pelrine mostra sobre a dificuldade inerente da estimativa

• Joseph Pelrine, um dos primeiros Certified Scrum Trainer da Europa, estudou agilidade em software a partir da lente da ciência da complexidade social
• Ele conduziu um experimento com mais de 300 pessoas que trabalham com desenvolvimento ágil de software, posicionando atividades cotidianas nas áreas do framework Cynefin (modelo de sensemaking de Dave Snowden)
  • O Cynefin classifica problemas em quatro domínios: Clear, Complicated, Complex e Chaotic
• A estimativa de trabalho foi colocada de forma consistente e repetida no domínio Complex
• A diferença entre Complicated e Complex é o ponto-chave:
  • No domínio Complicated, relações de causa e efeito podem ser compreendidas, especialistas conseguem rastreá-las e o conhecimento especializado gera previsões confiáveis
  • No domínio Complex, relações de causa e efeito só podem ser entendidas em retrospecto, porque o sistema é intrincado demais, dependente de contexto e sensível a pequenas mudanças
• É por isso que desenvolvimento de software não é manufatura: quase sempre estamos construindo algo que nunca existiu antes, sobre uma base de código única e com uma dinâmica de equipe única
  • É por isso que a analogia do carpinteiro não funciona: um armário é mais ou menos parecido com outro armário, mas uma funcionalidade não é mais ou menos parecida com outra funcionalidade
• Até equipes excelentes conseguem apenas estimativas medianas, não por falta de habilidade, mas porque existe um limite inerente de precisão no domínio Complex
• O objetivo não é acertar a estimativa, e sim tomar decisões úteis apesar da imprecisão inerente

O que o Cone of Uncertainty nos diz

• O conceito de Cone of Uncertainty de Steve McConnell: no início de um projeto, o erro de estimativa pode chegar a um fator de 4 para mais ou para menos (uma faixa total de 16x)
• À medida que o projeto avança e elementos desconhecidos são resolvidos — requisitos ficam claros, a arquitetura se define, problemas difíceis são descobertos e solucionados — o cone se estreita
• A ironia: o momento em que a estimativa fica mais precisa é pouco antes da conclusão, justamente quando ela é menos necessária
  • No início, quando ela é mais útil (porque ainda é possível mudar de direção ou cancelar o projeto), é quando se sabe menos
  • E é exatamente nesse estágio inicial que a maioria das organizações faz os compromissos mais firmes
• Há ainda duas implicações adicionais:
  • O cone representa o melhor caso de estimadores experientes, e a maioria das equipes fica abaixo disso
  • Fixar uma data já na fase de conceito inicial não é planejamento, e sim fazer um desejo e montar um cronograma em torno dele
  • O cone só se estreita por decisões que removem incerteza, não pela passagem do tempo
  • Definir escopo, resolver incógnitas de arquitetura, escrever código real e descobrir dificuldades estreita o cone; passar 3 semanas só em reuniões não estreita
• É preciso comunicar explicitamente às partes interessadas que "a qualidade da estimativa depende de onde estamos no cone"
  • Na primeira semana, não dá para fornecer um número de duas semanas, mas dá para oferecer uma faixa e explicar o que precisa ser verificado para estreitá-la
  • A maioria das partes interessadas aceita isso quando o cone é explicado; o problema é que ninguém lhes disse que era permitido pedir uma faixa

Por que usar a escala de Fibonacci

• A não linearidade da escala de Fibonacci (1, 2, 3, 5, 8, 13, 21) cumpre uma função epistemológica
• A diferença entre 2 e 3 é apenas uma "detecção aproximada de diferença", mas o salto de 8 para 13 codifica que a faixa de incerteza é maior do que a própria estimativa
  • Uma história de 13 pontos não significa "exatamente 13", mas "claramente mais incerta que 8 e ainda não tanto quanto 21"
• O espaçamento entre números de Fibonacci reflete como a complexidade realmente se expande
  • Coisas pequenas podem ser estimadas de forma aproximada; coisas grandes têm tantas incógnitas, pontos de integração e imprevistos que se tornam exponencialmente mais difíceis de prever
  • Uma história de 21 (ou 13) pontos ou mais significa: ainda não entendemos o trabalho o suficiente e precisamos dividi-lo
• Outra função subestimada das estimativas com Fibonacci é o que acontece durante a conversa de estimativa
  • Se uma pessoa diz 3 e outra diz 13, o número em si quase não importa; o que importa é por que a mesma equipe está vendo a mesma história de forma tão diferente
  • Pode ser que um lado tenha identificado uma dependência, ou conheça uma restrição técnica que não estava no ticket
• O maior valor da estimativa não está no número, mas em verificar se houve entendimento compartilhado
  • Quando esse mecanismo de forçar alinhamento é removido, muitas vezes o entendimento comum só surge quando alguém encontra complexidade escondida no terceiro dia de trabalho
• É por isso que é difícil concordar com a crítica do #NoEstimates de que "reuniões de estimativa são desperdício": quando bem conduzidas, elas geram alinhamento (alignment) naquela conversa
  • A resposta para reuniões mal conduzidas não é cancelá-las

A armadilha do compromisso (Commitment Trap) e como evitá-la

• A disfunção mais profunda à qual o movimento #NoEstimates reagiu foi: estimativas são convertidas em compromissos por pressão social, não por lógica
• Um modo de falha relacionado: quando pessoas que não executam o trabalho criam cronogramas e os jogam para a equipe, surge a pior combinação possível: estimativas imprecisas + equipe sem senso de posse sobre os números
  • Quando a realidade diverge, ninguém sabe de quem é a responsabilidade, então todos culpam todos
  • Quem executa o trabalho deve sempre ser dono da estimativa; impor uma estimativa de fora não é otimismo, e sim prenúncio de jogo de culpa
• Quando a obsessão por prazo se instala, toda conversa converge para "como vamos cumprir o prazo?", e a pergunta sobre se estamos construindo a coisa certa desaparece do campo de visão
• É preciso separar três coisas que a maioria das organizações confunde:
  1. Estimativa (Estimate): previsão probabilística dada a incerteza atual, que precisa vir acompanhada de faixa e premissas explícitas
     • Ex.: "consideramos 4 a 6 semanas, assumindo que não haja mudanças de requisitos e que as perguntas sobre a API sejam respondidas até a próxima sexta-feira"
  2. Plano (Plan): compromisso com o processo, não com o resultado
     • Ex.: "vamos trabalhar por 2 semanas, revisar o progresso e fornecer uma previsão atualizada"
  3. Compromisso (Commitment): promessa sobre o resultado, que deve ser rara e feita com cautela, apenas quando o cone já tiver se estreitado o suficiente
     • Fazer compromisso ainda na fase inicial de conceito não é ousadia, é imprudência
     • Quando houver pressão por um compromisso, tente obter um compromisso sobre prioridades, não sobre cronograma; e, se nem isso funcionar, inclua o nível de confiança como parte do compromisso
• A prática organizacional de tratar toda estimativa como compromisso no instante em que ela é dita é a raiz da disfunção
  • Dá para entender a solução política do #NoEstimates (simplesmente não dizer números), mas o custo é perder a capacidade organizacional de alocar recursos, ordenar dependências e manter conversas honestas com stakeholders externos
• A solução melhor é ensinar o cone, educar stakeholders e explicitar a distinção entre estimativa e compromisso sempre que um número for dado
  • É mais difícil e leva mais tempo do que recusar estimativas, mas em vez de evitar situações em que a confiança pode se quebrar, isso constrói confiança

Boas práticas de estimativa

• Estime mais tarde: como o cone só se estreita com aprendizado, primeiro faça spikes, escreva código exploratório e converse com as equipes de integração
  • É preciso resistir à pressão para dar números antes de haver aprendizado suficiente para torná-los significativos
• Evite decomposição excessiva antes de começar: diante da incerteza, é tentador quebrar o trabalho em pedaços menores, mas decompor o bastante não garante uma estimativa confiável
  • Planejamento prévio detalhado demais acaba enrijecendo, fazendo a equipe se apegar a algo que já não reflete a realidade, e a divergência se torna ainda mais confusa
  • O ideal é começar com um plano simples, fácil de ajustar
• Forneça faixas, não estimativas pontuais: "3 a 5 semanas" é mais honesto do que "4 semanas" e quase tão executável quanto
  • Se disserem que só é possível um número único, dê o ponto médio da faixa, mas deixando claro que é um ponto médio
  • Combine com stakeholders o uso do Cone of Uncertainty e faça referência a ele sempre que comunicar uma estimativa
• Torne as premissas visíveis: uma estimativa é tão boa quanto suas premissas, então explicite ausência de mudança de escopo, adoção de determinada abordagem técnica, entrega de outra equipe em certa data etc.
  • Premissas que ficam só na cabeça acabam virando mal-entendidos justamente no pior momento
• Acompanhe a precisão, mas sem punição: o objetivo é calibração, não culpa
  • Equipes que estimam juntas por 6 meses e revisam a precisão desenvolvem uma sensibilidade compartilhada sobre onde superestimam ou subestimam de forma sistemática
  • Se estimativas imprecisas forem punidas, a equipe passará a inflá-las por defesa, e estimativas infladas são menos úteis do que estimativas honestas, ainda que incertas
  • No domínio Complex, errar a estimativa não é defeito de caráter, e sim propriedade do domínio
• Acima de 8, divida: histórias Fibonacci de 13 ou 21 pontos quase sempre contêm complexidade oculta que ainda não veio à tona
  • O ato de dividir força a explicitar o que realmente se sabe
  • Com frequência, descobre-se que dois dos três subitens são pequenos, e toda a incerteza está concentrada em apenas um deles

A verdade incômoda para os dois lados

• Estimar é uma forma de comunicação, não um cálculo; seu propósito não é prever o futuro, mas apoiar coordenação e tomada de decisão sob incerteza
• Os modos de falha da estimativa não são aleatórios, mas sistemáticos: estimar cedo demais, tratar faixas como pontos, tratar estimativas como compromissos, ignorar a posição epistemológica do Cone of Uncertainty e impor estimativas a quem executa
• O que Dalmijn chama de Complex Work Estimation Fallacy: a crença de que, se estimarmos com mais frequência, melhorarmos o processo e trabalharmos juntos por mais tempo, no fim chegaremos a estimativas exatas
  • No domínio Complex, o limite da precisão da estimativa não é função da maturidade da equipe, mas do próprio domínio
  • Dá para melhorar, mas não para tornar preciso; confundir as duas coisas leva organizações a punirem equipes por algo que está, em essência, fora do controle delas
• Rejeitar estimativas é apenas abandonar o jogo da coordenação
  • Isso pode funcionar para equipes totalmente independentes, com deploy contínuo e sem compromissos externos, mas a maioria das carreiras não acontece nesse contexto
• A escolha não é entre "estimativas ruins" e "sem estimativas", mas entre estimativas inconscientes e de baixa qualidade (que a organização fará de qualquer jeito, com ou sem você) e estimativas explícitas, humildes, baseadas em faixas e com premissas visíveis
• Como a estimativa de trabalho está no domínio Complex, ela deve ser tratada com uma mentalidade de complexidade: explorar, observar, responder, estimar, acompanhar e calibrar em ciclos repetidos
• O cone não se estreita com espera, e sim com aprendizado