10.15 Estimativa e previsão

Visão geral e motivação

Toda equipe de software recebe a mesma pergunta: quando vai ficar pronto? Por trás dessa pergunta está a estimativa de esforço de desenvolvimento de software, a prática de prever quanto trabalho algo vai exigir antes de vocês tê-lo feito. É uma das coisas mais difíceis que fazemos e uma das mais fáceis de fazer mal. O problema é que o software é trabalho de descoberta. Vocês constroem algo que nunca existiu, e boa parte do que aprenderão sobre o problema só fica visível enquanto constroem. Prever o esforço de aprender é genuinamente diferente de prever o esforço de repetir uma tarefa conhecida.

Por que tratar isso como disciplina própria e não como um cantinho da gestão de projetos (capítulo 10.6)? Porque as falhas são tão consistentes e tão caras. As equipes rotineiramente se comprometem com datas únicas para as quais não têm evidência e depois as defendem muito além do ponto em que a realidade as contradisse. Os líderes confundem uma estimativa com uma promessa. Os contratos congelam um número produzido numa tarde e cobram as pessoas por ele durante um ano. O resultado é entrega atrasada, confiança erodida e uma cultura em que ninguém diz o que de fato acredita. Acertar isso é menos uma questão de matemática melhor e mais de honestidade: separar o que vocês sabem do que esperam e comunicar a incerteza como incerteza.

As apostas sobem acentuadamente em contextos corporativos e governamentais. As empresas financiam portfólios de iniciativas interligadas contra orçamentos anuais e esperam números firmes para alocar capital (capítulo 10.1). Os governos assumem compromissos públicos sob regras de dotação, assinam contratos de preço fixo e respondem a legisladores quando uma data escorrega. Nos dois mundos a pressão por produzir um número único e confiante é imensa, e a incerteza profunda que torna esse número pouco confiável não desaparece porque alguém importante quer certeza. Este capítulo defende uma postura diferente: estimem quando isso ajuda a decidir, prevejam com evidências e não com otimismo e digam a verdade sobre a faixa.

Princípios fundamentais

Uma estimativa é uma previsão, não uma promessa. Mantenham-na separada de metas e compromissos.
A incerteza é real, então expressem-na. Uma faixa com uma probabilidade vence uma falsa data única.
O passado prevê o futuro melhor que o otimismo. Prefiram o histórico medido a novos chutes.
Decomponham para entender, prevejam para se comprometer. Fatias pequenas reduzem tanto o risco quanto a necessidade de estimar.
Adotem a visão externa. Comparem com esforços passados semelhantes antes de confiar na sua história interna.
Refaçam a previsão continuamente. Uma previsão feita uma vez e nunca atualizada é decoração.
Estimem apenas quando a resposta mudará uma decisão. Caso contrário, é desperdício.

Recomendações

Separe a estimativa, a meta e o compromisso

O movimento mais útil de todo este capítulo não custa nada: manter distintas três ideias. Uma estimativa é a sua previsão honesta de quanto tempo algo vai levar, com sua incerteza anexada. Uma meta é um objetivo de negócio que vocês gostariam de atingir, como um lançamento numa feira ou um prazo regulatório. Um compromisso é uma promessa que vocês fazem a outra pessoa e pretendem cumprir. São três coisas diferentes, e fundi-las é como os projetos começam a mentir para si mesmos. Quando um líder ouve “cerca de três a cinco meses” e anota “três meses”, e a equipe de vendas promete a um cliente “doze semanas”, uma estimativa virou em silêncio um compromisso sem que ninguém decidisse aceitar o risco.

Digam qual dos três vocês estão dando, todas as vezes. Se pedirem uma data, respondam com uma estimativa expressa como faixa e depois deixem o negócio definir uma meta contra ela e decidir, deliberadamente, a que se comprometer. Um compromisso deve ser uma escolha feita de olhos abertos, pesando a incerteza da estimativa contra o custo de errar. Essa disciplina se liga diretamente a como a sua organização toma e registra decisões (capítulo 1.5): um compromisso é uma decisão e merece o rigor de uma decisão e não um aceno de corredor.

Entenda por que as estimativas erram, e em que direção

As estimativas de software não erram ao acaso. Erram de modos previsíveis e sistemáticos, e conhecer o padrão permite corrigi-lo. No início de qualquer esforço vocês estão dentro do cone da incerteza: no começo a sua estimativa pode facilmente estar errada por um fator de quatro em qualquer direção, e a faixa só se estreita à medida que vocês constroem e aprendem. Comprometer-se com um número preciso na boca larga do cone é se comprometer com uma cifra que vocês ainda não conseguem sustentar.

Por cima dessa incerteza estrutural fica um viés humano. A falácia do planejamento é a nossa tendência confiável de subestimar o tempo, o custo e o risco dos nossos próprios planos enquanto imaginamos o melhor caso. Visualizamos o caminho feliz, esquecemos as interrupções, as surpresas de integração e os dias de doença e produzimos um número que presume que nada dá errado. A folga é a resposta defensiva usual, mas a folga acrescentada por sentimento é só um segundo chute empilhado sobre o primeiro e é negociada fora no instante em que os cronogramas apertam. A cura não é mais força de vontade; é método. Baseiem as previsões no que trabalhos semelhantes de fato levaram e não em como este trabalho parece por dentro.

Use a decomposição e o julgamento de especialistas, e conheça os limites deles

As técnicas de trabalho pesado valem ser conhecidas e delimitadas. A decomposição quebra uma entrega grande em peças menores sobre as quais se pode raciocinar e depois as consolida. Ajuda porque as pessoas estimam coisas pequenas e familiares muito melhor que coisas grandes e vagas, e porque somar muitos itens independentes permite que algumas superestimativas cancelem algumas subestimativas. Seu limite é que a decomposição perde o trabalho entre as caixas: integração, coordenação e as tarefas que vocês não pensaram em listar. O julgamento de especialistas e a estimativa por analogia (“isso é como o módulo de relatórios que construímos no ano passado, que levou dois meses”) são rápidos e muitas vezes surpreendentemente bons, mas herdam o otimismo e os pontos cegos de quem estima.

Para qualquer coisa a que vocês precisem pôr um número, prefiram a estimativa de três pontos, que pede um valor otimista, um mais provável e um pessimista e os combina, muitas vezes como a média ponderada PERT (otimista mais quatro vezes o mais provável mais pessimista, dividido por seis). O valor não está na fórmula precisa. Está em que a estimativa de três pontos força vocês a declarar a incerteza em voz alta e produz uma faixa em vez de um falso ponto. Os métodos de dimensionamento relativo como os pontos de história e os tamanhos de camiseta (pequeno, médio, grande, extragrande) contornam a armadilha de prever horas exatas comparando os itens entre si. Funcionam bem para ordenar e para capacidade aproximada, mas tratem-nos como insumos de uma previsão, não como moeda. Pontos não são horas, e multiplicar a velocidade pelos pontos para produzir uma data reintroduz todos os problemas que o dimensionamento relativo pretendia evitar.

Preveja de modo probabilístico a partir dos seus próprios dados de fluxo

Eis a mudança que muda tudo: parem de pedir às pessoas que adivinhem quanto tempo o trabalho vai levar e comecem a medir com que rapidez a sua equipe de fato termina o trabalho. O seu pipeline de entrega (capítulo 11.2) já produz os dados de que vocês precisam. Se vocês acompanham a vazão, o número de itens que a equipe conclui por semana, podem prever o futuro a partir do passado em vez da esperança. Uma equipe que fechou de seis a onze itens por semana nos últimos três meses levará, com alta probabilidade, aproximadamente de quatro a sete semanas para terminar quarenta itens restantes. Essa previsão repousa em evidências e se atualiza sozinha toda semana conforme chegam novos dados.

A versão rigorosa roda uma simulação pelo método de Monte Carlo: amostrar milhares de vezes a sua vazão semanal histórica para construir uma distribuição de datas de término possíveis e depois ler a resposta como uma probabilidade. “Temos 85% de chance de terminar até 14 de março e 50% até 28 de fevereiro” é uma afirmação muito mais útil e honesta que “ficará pronto em 1º de março”. Essa abordagem se liga diretamente à teoria das filas (capítulo 11.3): o prazo de entrega é igual ao trabalho em andamento dividido pela vazão, de modo que as mesmas métricas de fluxo que governam como o trabalho se move também governam quando ele chegará. A previsão probabilística precisa de histórico e de um processo razoavelmente estável, que é exatamente por que recompensa as equipes que mantêm o trabalho pequeno e o fluxo constante. Também remove em silêncio a maior parte da cerimônia de estimativa, porque vocês já não precisam dimensionar cada item para saber quando o lote aterrissará.

Adote a visão externa para os grandes programas

Para programas grandes, longos e caros, as estimativas individuais e até as previsões de fluxo podem enganar, porque um programa inédito ainda não tem histórico de vazão e sua história interna é exatamente onde a falácia do planejamento morde mais forte. O antídoto é a previsão por classe de referência: achem uma classe de referência de esforços concluídos semelhantes, olhem quanto tempo e quanto dinheiro eles de fato levaram e situem o seu programa nessa distribuição antes de confiar no seu próprio plano de baixo para cima. Se substituições comparáveis de plataforma na sua empresa estouraram suas estimativas iniciais em 60% em média, esse número é uma evidência melhor sobre o seu do que o plano arrumadinho que a sua equipe acabou de montar. A visão externa soa desanimadora, e é exatamente esse o seu valor: contraria o otimismo que todo plano novo carrega. Usem-na para financiar o portfólio e orçar megaprogramas (capítulo 10.1), onde o custo de um estouro sistemático se mede em milhões e em credibilidade.

Estime menos fatiando menor e sequencie pelo custo do atraso

Às vezes a quantidade certa de estimativa é quase nenhuma. O argumento do #NoEstimates, em seu núcleo razoável, observa que se vocês fatiam o trabalho em peças pequenas o bastante para que cada uma leve um dia ou dois, a estimativa de qualquer peça isolada deixa de importar. Vocês simplesmente contam a vazão e preveem a partir da contagem. Quando as fatias são uniformes e pequenas, o dimensionamento elaborado é desperdício: consome esforço produzindo uma precisão de que a previsão não precisa. Isso não é um argumento contra pensar adiante. É um argumento para tornar baratas as previsões individuais tornando pequenas as peças individuais.

O que ainda precisa de decisão é a ordem. Quando vocês não conseguem fazer tudo de uma vez, sequenciem pelo custo do atraso: o valor que vocês perdem a cada unidade de tempo em que uma dada peça de trabalho está atrasada. Uma funcionalidade que destrava um grande contrato no próximo trimestre tem um custo de atraso alto e deve passar à frente de um item desejável com custo nenhum, mesmo que o desejável seja mais fácil. Pesar o custo do atraso contra o esforço (a heurística “weighted shortest job first” do pensamento enxuto) diz o que fazer a seguir de modo muito mais confiável do que um backlog ordenado por instinto. Notem que isso reenquadra toda a conversa: em vez de “quando tudo estará pronto”, que convida à falsa precisão, vocês perguntam “qual é a coisa mais valiosa a terminar a seguir”, que vocês conseguem de fato responder.

Compromissos: prós e contras

Abordagem	Prós	Contras
Estimativa de data única	Simples. O que as partes interessadas pedem	Precisamente errada. Esconde o risco. Vira um compromisso acidental
Estimativa de três pontos / PERT	Força a incerteza a aparecer. Barata	Ainda um chute. A fórmula implica falso rigor
Pontos de história / tamanhos de camiseta	Rápidos. Bons para ordenar e para capacidade aproximada	Não são horas. A matemática da velocidade reintroduz datas únicas
Previsão probabilística de fluxo	Baseada em evidências. Autoatualizável. Faixas honestas	Exige histórico e fluxo estável. Parece menos “certa”
Previsão por classe de referência	Corrige o otimismo nos grandes programas	Exige esforços passados comparáveis. Desanimadora de ouvir
#NoEstimates (fatias pequenas)	Remove desperdício. Previsão por contagem	Exige fatiamento disciplinado. Desconcertante para financiadores que querem um número

A tensão central é a certeza que as pessoas querem versus a honestidade que o trabalho exige. Financiadores, executivos, contratos e legisladores pedem uma data única firme porque uma data única é fácil de orçar, prometer e defender. O software raramente a sustenta. Resolvam a tensão não fabricando certeza nem recusando responder, mas respondendo na moeda da probabilidade: uma faixa com níveis de confiança, refeita conforme a evidência chega. Combinem-na com fatias pequenas para que entregas iniciais e reais substituam as distantes e imaginárias como aquilo em que as pessoas confiam. Um incremento demonstrado vale mais que qualquer estimativa.

Perguntas para discutir com sua equipe

Quando alguém pede uma data a vocês, estão dando uma estimativa, uma meta ou um compromisso, e todos na sala sabem qual? Esta é a pergunta que previne mais dano pelo menor esforço. Na maioria das organizações essas três coisas colapsam num só número no instante em que ele sai da boca da equipe, e ninguém decidiu aceitar o risco de uma previsão virar promessa. Levem um exemplo real: peguem o seu último prazo comprometido e rastreiem-no de volta até a conversa em que foi pronunciado pela primeira vez e perguntem se alguma vez foi algo além de um chute esperançoso vestindo terno. A resposta deve mudar a sua linguagem para sempre, de modo que as estimativas saiam como faixas, as metas sejam nomeadas como desejos de negócio e os compromissos sejam assumidos deliberadamente, com a incerteza pesada e registrada como uma decisão (capítulo 1.5). Se a sua equipe não consegue apontar onde um compromisso foi conscientemente aceito, vocês estão fazendo promessas por acidente.
Vocês conseguiriam prever o seu próximo lançamento a partir da vazão medida em vez de novas estimativas, e o que está impedindo? A maioria das equipes já tem os dados para responder empiricamente “quando ficará pronto”, parados sem uso na ferramenta que acompanha o trabalho. Se vocês sabem quantos itens a equipe concluiu por semana no último trimestre, podem simular uma distribuição de datas de término e citar uma probabilidade em vez de um desejo. Levem o seu histórico real de vazão e a contagem de itens restantes e comparem a previsão baseada em fluxo com a data que a equipe estimou por sentimento; a diferença costuma ser instrutiva. Se o bloqueio é que os seus itens têm tamanhos muito diferentes ou o seu fluxo é errático, isso em si é o achado, porque um fluxo instável é um problema de entrega que vale consertar seja como for (capítulos 11.2, 11.3). Passar da estimativa para a medição costuma ser menos uma mudança de ferramenta e mais uma decisão de confiar no próprio histórico em vez do otimismo.
Para o seu maior programa atual, vocês adotaram a visão externa, ou só construíram um plano interno? Os grandes programas são onde o otimismo se compõe em estouros caros e onde um plano confiante de baixo para cima é mais sedutor e menos confiável. A disciplina é nomear uma classe de referência de esforços concluídos semelhantes dentro ou fora da sua organização, achar o que eles de fato custaram e quanto tempo de fato levaram e situar honestamente o seu programa nessa distribuição antes de defender os seus próprios números. Levem os dados: como as iniciativas comparáveis aqui estouraram suas primeiras estimativas, e o seu plano atual presume em silêncio que vocês vencerão todas elas? Se presume, vocês estão apostando em ser excepcionais, uma aposta que as taxas de base confiavelmente perdem. A visão externa tornará a sua previsão menos lisonjeira e muito mais defensável perante os financiadores e auditores que lembrarão o número que vocês deram (capítulo 10.1).
Quando um financiador, um contrato ou um legislador exige uma data fixa, como vocês respondem sem mentir nem recusar? É aqui que a pressão é mais feroz e onde as equipes honestas mais cedem, porque “70% de chance até setembro” soa evasivo ao lado do confiante “setembro” de um concorrente. Para uma grande organização as apostas se multiplicam: uma data fixa se propaga para orçamentos, programas dependentes e promessas públicas, de modo que um número escolhido por conforto vira um passivo sistêmico no instante em que escorrega. Levem a linguagem que vocês de fato pretendem usar, um exemplo resolvido de uma faixa com níveis de confiança e um pequeno incremento inicial com que vocês possam se comprometer firmemente enquanto deixam o escopo posterior como uma faixa financiada. A consideração contrária é real, já que alguns prazos (uma virada regulatória, um lançamento numa feira) são genuinamente fixos, e o movimento certo ali é fixar a data e flexionar o escopo em vez de fingir que o esforço é certo. Em contextos corporativos e governamentais, liguem isso a como o contrato é moldado: um acordo modular e financiado por incrementos permite comprometer-se com honestidade com um núcleo valioso, enquanto um único contrato de preço fixo e escopo fixo ancorado num marco distante força exatamente a falsa certeza que produz o estouro e a manchete.
Como a sua equipe decide o que construir a seguir, e sequenciar explicitamente pelo custo do atraso mudaria a ordem? A maioria dos backlogs é ordenada por uma mistura de instinto, de quem gritou mais alto e de esforço aproximado, o que otimiza em silêncio as vitórias fáceis e não as valiosas. O custo do atraso, o valor que vocês perdem a cada unidade de tempo em que um trabalho está atrasado, reenquadra a pergunta de “quando tudo estará pronto” para “qual é a coisa mais valiosa a terminar a seguir”, que vocês conseguem responder com evidências. Levem três ou quatro itens reais do backlog com uma estimativa honesta do valor que cada um destrava e de quando esse valor expira e depois ordenem-nos por valor perdido por semana contra o esforço e comparem essa ordem com o plano atual; a reordenação costuma ser surpreendente e difícil de contestar. A consideração contrária é que o custo do atraso é em si uma estimativa e pode ser manipulado por quem quer o seu item primeiro, então nomeiem quem é dono dos números e como são questionados. Para um portfólio corporativo ou um programa governamental, essa disciplina é o que permite defender decisões de sequenciamento perante partes interessadas que acreditam, cada uma, que a sua iniciativa deve vir primeiro, porque a ordem repousa em valor declarado e não em política.
Quem refaz a previsão, com que frequência e quem responde por agir quando a previsão se move? Uma previsão feita uma vez no início e nunca revisitada é decoração, e os escorregões mais caros são os que uma previsão viva teria mostrado meses antes de o prazo os tornar inegáveis. Para uma grande equipe a falha raramente é a ausência de dados e quase sempre a ausência de uma cadência permanente e de um dono nomeado: a vazão deriva, a distribuição de datas de término se desloca para a direita e ninguém cujo trabalho é notar está olhando. Levem o seu ritmo real de refazer a previsão (ou admitam que não há), a última vez que uma previsão mudou uma decisão e a deriva que vocês viram desde que o compromisso atual foi fixado. A consideração contrária é a fadiga de previsões, já que refazê-las de modo barulhento demais convida à agitação e erode a confiança, então combinem um intervalo sensato e um limiar que dispare o escalonamento em vez de reagir a cada oscilação. Em contextos corporativos e governamentais, liguem isso à supervisão: informem os órgãos de governança com a faixa de probabilidade atualizada numa agenda fixa, para que um escorregão apareça como uma previsão refeita e gerida em que os líderes possam agir e não como uma surpresa revelada no marco.

Perspectiva por setor

Startup. Pulem quase por completo a cerimônia de estimativa. Fatiem o trabalho em peças de um a dois dias, contem o que terminam a cada semana e deem aos fundadores e investidores uma faixa que se estreita em vez de uma data única heroica. O seu histórico é curto e o seu processo é volátil, então apoiem-se no cone da incerteza como explicação honesta e não como desculpa e refaçam a previsão toda sexta-feira conforme o quadro se aguça.

Pequena empresa. Vocês não têm especialista em estimativa nem apetite por reuniões de dimensionamento, então deixem as ferramentas que já operam fazerem o trabalho: a maioria dos rastreadores de tarefas expõe a vazão de graça, e uma previsão leve a partir dela vence um prazo chutado. Resistam à vontade de comprar software pesado de planejamento que vocês não conseguem manter com equipe; uma contagem semanal simples de itens concluídos e uma faixa simples respondem “quando ficará pronto” bem o bastante para os compromissos que vocês de fato assumem com clientes.

Grande empresa. O problema é a consistência entre muitas equipes financiando um portfólio contra um ciclo anual de capital (capítulo 10.1). Padronizem faixas com níveis de confiança em vez de datas únicas, exijam comparações com classes de referência para os grandes programas e montem métricas de fluxo para que chutes deem lugar a previsões baseadas em vazão em um trimestre. Governem a estimativa como uma prática compartilhada, com definições claras de estimativa, meta e compromisso, para que um número produzido numa divisão signifique a mesma coisa quando chega ao conselho.

Governo. A contratação e a prestação de contas públicas moldam tudo. Uma data pública perdida vira manchete e achado de auditoria, então prefiram contratos modulares financiados por incrementos a um único compromisso de preço fixo e escopo fixo ancorado num marco distante. Informem os órgãos de supervisão com previsões probabilísticas e evidência de classe de referência em linguagem simples, publiquem os níveis de confiança com honestidade e deixem os incrementos funcionando demonstrados virarem a evidência em que o público e os auditores confiam em vez da assinatura de um contratado num plano otimista.

Exemplos

Startup. Uma startup de nove pessoas que se prepara para sua demonstração da Série A precisa saber se uma integração-chave estará pronta. Em vez de deixar os fundadores prometerem uma data aos investidores, o líder cita uma estimativa como faixa e explica o cone da incerteza por trás dela. A equipe vem fechando de cinco a nove itens do backlog por semana, então roda uma rápida previsão de Monte Carlo sobre o trabalho restante e relata “80% de chance até a terceira semana do trimestre, chance igual uma semana antes”. Fatiam a integração em peças de dois dias para que nenhuma estimativa isolada importe muito, sequenciam pelo custo do atraso para construir primeiro o caminho visível aos investidores e refazem a previsão toda sexta. Os investidores recebem uma projeção honesta e que se estreita em vez de um número confiante que teria escorregado.

Grande empresa. Uma varejista que substitui sua plataforma de gestão de pedidos precisa financiar o programa por um ciclo anual de capital que exige um número. O escritório do programa resiste à vontade de defender o plano arrumadinho de baixo para cima e em vez disso constrói uma classe de referência a partir de três substituições de plataforma comparáveis, duas internas e uma publicamente documentada, que estouraram suas estimativas iniciais em 50% a 80%. Financiam contra a cifra da visão externa, expressam o cronograma como uma faixa de probabilidade e não como um go-live fixo e montam métricas de fluxo a partir da primeira equipe que entrega, de modo que em um trimestre o chute seja substituído por uma previsão baseada em vazão que se atualiza mensalmente. Quando uma frente corre quente, a previsão refeita mostra isso cedo, e a liderança reequilibra em vez de descobrir o escorregão no prazo final.

Governo. Uma agência que moderniza um sistema de benefícios opera sob dotações e escrutínio público, onde uma data pública perdida é manchete. Em vez de um único contrato de preço fixo e escopo fixo ancorado num marco distante, contrata incrementos modulares e se compromete publicamente com um núcleo valioso entregue cedo, com o escopo posterior expresso como uma faixa financiada e não como uma promessa. Os líderes do programa informam os órgãos de supervisão com previsões probabilísticas e comparações de classe de referência, explicando os níveis de confiança em linguagem simples, de modo que um “70% até setembro” seja entendido exatamente como isso. Os incrementos funcionando demonstrados viram a evidência em que o público confia, que é mais sólida que qualquer estimativa que um contratado pudesse assinar.

Justificativa de negócio: motivações, ROI e TCO

O retorno de estimar e prever com honestidade é dominado pela catástrofe evitada. Os grandes esforços de software estouram ou fracassam com muito mais frequência do que cumprem um plano fixo original, e as perdas se compõem: custo afundado, valor perdido pela entrega tardia, gasto de emergência para recuperar e a erosão da confiança que se segue a um compromisso público quebrado. As práticas aqui (separar a estimativa do compromisso, prever a partir da vazão real, adotar a visão externa nos grandes programas) são as que tiram um programa dessa curva de fracasso. Vocês não estão comprando uma bola de cristal mais exata. Estão comprando informação mais cedo e mais verdadeira sobre onde estão, o que permite corrigir enquanto a correção ainda é barata.

No custo total de propriedade, a passagem da cerimônia de estimativa para a previsão medida costuma baixar o custo em vez de elevá-lo. A estimativa elaborada de antemão é cara de produzir e decai no instante em que o trabalho começa, enquanto uma previsão baseada em vazão é quase de graça assim que o seu pipeline de entrega emite os dados. Os dois extremos custam dinheiro: superestimar (reuniões intermináveis de dimensionamento produzindo uma precisão que ninguém usa) e subprever (comprometer-se às cegas e pagar o estouro depois). Para defender o caso junto à liderança, ponham o custo totalmente carregado do seu último grande estouro ao lado do custo quase zero de acompanhar a vazão e citar faixas e mostrem como uma previsão de visão externa teria fixado desde o início uma expectativa financiável.

Antipadrões e armadilhas

Compromissos de data única: uma faixa colapsada num só número e depois defendida além da evidência.
Lavagem de estimativas: um chute esperançoso passado pela cadeia até endurecer numa promessa contratual.
Velocidade como motor de cronograma: multiplicar pontos de história pela velocidade para fabricar uma data precisa.
Folga por sentimento: um segundo chute empilhado sobre o primeiro, negociado fora sob pressão.
Só a visão interna: confiar num plano novo de baixo para cima ignorando o que programas semelhantes de fato levaram.
Estimar tudo: dimensionar fatias minúsculas e uniformes cujas estimativas individuais não mudam nenhuma decisão.
Previsões congeladas: uma previsão feita uma vez no início e nunca atualizada conforme a realidade chega.
Teatro da precisão: citar horas com duas casas decimais na boca larga do cone da incerteza.

Modelo de maturidade

Nível 1, Iniciar: As estimativas são datas únicas produzidas por instinto e tratadas como promessas. Não há distinção entre estimativa, meta e compromisso. A previsão é reativa e ad hoc. Os estouros surpreendem todos e são atribuídos à equipe.
Nível 2, Desenvolver: Existe alguma estimativa estruturada (decomposição, pontos de história, cifras de três pontos), mas a prática varia de equipe para equipe. As estimativas ainda são em sua maioria números únicos. A velocidade é usada para projetar datas. As previsões são feitas uma vez no início e raramente revisitadas.
Nível 3, Padronizar: Um padrão documentado é imposto em toda a organização: as estimativas são expressas como faixas com incerteza declarada, estimativa, meta e compromisso são mantidos distintos por definição, as equipes acompanham a vazão e refazem a previsão numa cadência definida e os grandes programas são obrigados a usar comparações de classe de referência.
Nível 4, Gerenciar: A prática é medida e controlada com dados. A exatidão da previsão é acompanhada contra os resultados reais e a calibração é conferida, de modo que se possa dizer se as datas “80% até” de fato caem oito vezes em dez. As linhas de base de vazão e de tempo de ciclo são mantidas, o custo do atraso é quantificado, a deriva da previsão é monitorada contra limiares e dispara escalonamento e os compromissos são assumidos contra evidências e não contra otimismo.
Nível 5, Orquestrar: A previsão probabilística a partir de dados de fluxo é contínua e confiável porque o histórico de calibração a provou honesta. Os compromissos são decisões deliberadas que pesam a confiança contra o custo. O trabalho é fatiado pequeno o bastante para que a estimativa seja mínima e o custo do atraso conduza a sequência. A estimativa é integrada ao financiamento do portfólio e ao planejamento de riscos, e a organização rotineiramente redefine o escopo e reequilibra conforme as previsões se movem, adaptando o plano à evidência em vez de defender o número original.

Ideias para discussão

O que mudaria na sua organização se toda estimativa tivesse de sair da equipe como uma faixa com um nível de confiança e as datas únicas fossem proibidas?
Onde vocês estão gastando esforço estimando trabalho que já é pequeno e uniforme o bastante para ser previsto por contagem?
Se vocês alimentassem uma simulação de Monte Carlo com os seus dois últimos trimestres de vazão, a previsão concordaria com as datas a que vocês de fato se comprometeram?
Para o seu maior programa, qual é a classe de referência honesta, e quão mal a taxa de base contradiz o seu plano atual?
Como a sua equipe decide a sequência hoje, e ordenar explicitamente pelo custo do atraso mudaria o que vocês constroem a seguir?
Quando um compromisso é aceito na sua organização, a incerteza é registrada como parte da decisão, ou ela some no instante em que a data é escrita?

Principais conclusões

Mantenham distintas a estimativa, a meta e o compromisso. Fundi-las é como os projetos começam a mentir para si mesmos.
As estimativas erram de modo sistemático em direções conhecidas: o cone da incerteza alarga o trabalho inicial e a falácia do planejamento faz do otimismo o padrão.
Prefiram a previsão probabilística a partir da vazão medida a novos chutes. Citem faixas e níveis de confiança e refaçam a previsão continuamente.
Adotem a visão externa com a previsão por classe de referência nos grandes programas, onde o otimismo é mais caro (capítulo 10.1).
Fatiem pequeno para que as estimativas individuais deixem de importar e sequenciem pelo custo do atraso em vez de pelo instinto.
Estimem apenas quando isso muda uma decisão. Caso contrário, é desperdício. Vejam os capítulos 10.6 (gestão de projetos), 11.2 (entrega), 11.3 (teoria das filas) e 1.5 (tomada de decisão e governança).

Referências e leitura complementar

Steve McConnell, Software Estimation: Demystifying the Black Art.
Daniel Vacanti, Actionable Agile Metrics for Predictability and When Will It Be Done? (probabilistic forecasting from flow data).
Troy Magennis, Forecasting and Simulating Software Development Projects (Monte Carlo methods).
Bent Flyvbjerg and Dan Gardner, How Big Things Get Done (reference class forecasting and megaprojects).
Daniel Kahneman, Thinking, Fast and Slow (the planning fallacy and the outside view).
Donald Reinertsen, The Principles of Product Development Flow (cost of delay and queue economics).
Vasco Duarte, NoEstimates: How to Measure Project Progress Without Estimating.
Frederick Brooks, The Mythical Man-Month (why software schedules go wrong).
Todd Little, “Schedule Estimation and Uncertainty Surrounding the Cone of Uncertainty” (IEEE Software, 2006).