Estimativa e planejamento ágil: pontos, velocidade e previsões

Toda estimativa é uma afirmação sobre um trabalho que ninguém fez ainda, feita por pessoas que vão aprender, durante a execução, coisas que não têm como saber antes. Isso não é falta de profissionalismo; é a própria definição da situação. Estimar software é difícil porque a maior parte do esforço está em descobrir qual é de fato o problema, e essa descoberta só acontece enquanto se constrói.

O objetivo útil, portanto, não é a precisão. É produzir previsões honestas o suficiente para embasar decisões, baratas o suficiente para compensar o tempo gasto e expressas de um jeito que preserve a incerteza, em vez de escondê-la atrás de um único número cheio de confiança. Este guia apresenta as técnicas que times ágeis usam, como prever uma release sem fingir e o que o argumento do não estimar tem de certo. A construção clássica de cronogramas com diagramas de rede, que resolve outro problema, é tratada em gerenciamento do cronograma.

Por que estimativas são incertas

Três fontes de erro distintas se somam.

Desconhecimento do problema. Os requisitos, como são escritos, são sempre uma aproximação da necessidade. A distância entre os dois é descoberta construindo, o que significa que parte do trabalho é, por definição, desconhecida no momento da estimativa. É isso que o cone da incerteza descreve: no estágio de concepção, uma estimativa defensável pode errar por um fator de quatro para mais ou para menos, e a margem se estreita à medida que o problema é entendido, desaparecendo só na entrega.

Desconhecimento da solução. Ninguém sabe o quão feia é a integração com o sistema legado até abri-la. Estimativas para trabalho em partes pouco conhecidas de um sistema são sistematicamente piores do que para partes conhecidas, e o erro é assimétrico: surpresas só alongam o trabalho, quase nunca o encurtam.

Vieses humanos. As pessoas imaginam o cenário em que nada dá errado e se ancoram no primeiro número dito na sala. A tendência a estimar como se o plano fosse se manter está bem documentada, e a correção não é exigir chutes melhores, mas usar o histórico observado de trabalhos comparáveis.

Há uma quarta fonte, organizacional: uma estimativa dada sob pressão a um stakeholder que queria um número menor é resultado de uma negociação, não uma previsão. Qualquer processo que puna estouros vai gerar gordura escondida, e qualquer processo que recompense o otimismo vai gerar subestimativas.

Dimensionamento relativo e story points

A estimativa relativa contorna a pergunta mais difícil. Pessoas julgam mal a duração absoluta e são bem melhores comparando: pergunte a um time se este item é maior que aquele e ele converge rápido.

Um story point é uma unidade de tamanho relativo que combina volume, complexidade e incerteza. Ele não tem valor em tempo. A escala costuma ser uma sequência de Fibonacci modificada — 1, 2, 3, 5, 8, 13, 20 — porque os intervalos crescentes refletem o fato de que a precisão cai à medida que o tamanho aumenta; distinguir um 8 de um 13 é possível, distinguir um 21 de um 23 não é. Alguns times usam tamanhos de camiseta pelo mesmo motivo.

O dimensionamento relativo só funciona com histórias de referência: dois ou três itens concluídos de que o time inteiro se lembra, fixados em valores específicos. "Adicionar um campo obrigatório com validação ao formulário existente" vale 2; "a importação de CSV com relatório de erros" valeu 5. Itens novos são posicionados por comparação. Sem referências, o valor dos pontos deriva ao longo dos meses e qualquer dado histórico perde o valor.

O planning poker é o mecanismo habitual. Cada desenvolvedor segura uma carta, todos revelam ao mesmo tempo para que ninguém se ancore na voz mais sênior, e quem ficou nos extremos explica seu raciocínio antes de uma segunda rodada. A estimativa é um subproduto; o que importa é a conversa, porque uma grande dispersão quase sempre significa que duas pessoas estão imaginando escopos diferentes. Para backlogs grandes, a estimativa por afinidade — ordenar os cartões em silêncio numa parede por grupos de tamanho e depois atribuir valores aos grupos — dimensiona cinquenta itens em uma hora com precisão adequada.

Itens estimados em 13 ou mais, em geral, devem ser quebrados antes de entrar numa sprint, usando os padrões de divisão do guia do product owner.

Velocidade, usada do jeito certo

Velocidade é o número de pontos que o time conclui — atendendo à definition of done — em uma sprint. Seu único propósito legítimo é ajudar esse mesmo time a prever o próprio futuro.

Use uma faixa, não uma média. Um time cujas últimas seis sprints entregaram 26, 31, 18, 29, 33 e 24 pontos tem média de 26,8, mas planejar com 26,8 é praticamente um cara ou coroa. Planejar a sprint pela parte baixa da faixa e prever a release com toda a dispersão é muito mais informativo. Nunca mantenha a velocidade depois de uma mudança no time, nunca a compare entre times e nunca a divulgue como produtividade: pontos são uma unidade interna, e no momento em que passam a ser recompensados, eles inflam.

A velocidade também se degrada silenciosamente quando a definition of done é frouxa, porque trabalho inacabado vaza para a contagem. Se a velocidade está estável mas nada chega à produção, o número está medindo atividade.

Previsão a partir do fluxo

Muitos times obtêm previsões melhores ignorando o tamanho por completo e contando itens.

Throughput é o número de itens concluídos por unidade de tempo. Cycle time é o tempo decorrido entre começar um item e terminá-lo. Os dois são medidos, não estimados, e vêm de graça de qualquer ferramenta que registre transições de estado.

A ideia por trás da previsão baseada em fluxo é que, quando um time quebra o trabalho de forma consistente, os tamanhos dos itens ficam concentrados o bastante para que contá-los seja quase tão preditivo quanto somar pontos — e isso não custa nada. Se um time conclui entre quatro e nove itens por semana e restam oitenta, a release sai em algum ponto entre nove e vinte semanas, e você pode dizer isso já no primeiro dia.

A simulação de Monte Carlo transforma isso em uma distribuição. Pegue as amostras históricas de throughput semanal, sorteie valores delas repetidamente para simular a conclusão dos itens restantes, rode dez mil tentativas e leia os percentis.

Itens restantes:      80
Amostras de throughput semanal (últimas 12 semanas):
  4, 7, 5, 9, 6, 3, 8, 6, 5, 7, 4, 6

10.000 execuções simuladas — semanas para concluir 80 itens:
  Percentil 50 (P50)   13 semanas
  Percentil 70 (P70)   15 semanas
  Percentil 85 (P85)   17 semanas
  Percentil 95 (P95)   20 semanas

Mensagem para os stakeholders:
  "13 semanas é cara ou coroa. Temos 85% de confiança de concluir
   em até 17 semanas. Comprometer-se com 20 semanas é seguro."

É uma conversa muito mais útil do que "a release sai no terceiro trimestre", porque explicita o nível de confiança e pode ser recalculada toda semana conforme chegam dados reais. Acrescente um fator de crescimento de escopo se o backlog historicamente cresce durante a entrega — um ajuste comum e frequentemente esquecido.

O argumento do não estimar

Uma corrente de prática defende que, para muitos times, estimar é puro desperdício. O argumento é mais forte do que seus críticos admitem: se os itens são sempre quebrados em pedaços pequenos, a previsão por throughput dá a data sem estimativa nenhuma, e as horas gastas em sessões de dimensionamento não trazem nada em troca. Além disso, estimativas tendem a virar compromissos por mais cuidado que se tenha ao apresentá-las, o que as corrompe.

Os contra-argumentos também são reais. Conversas de estimativa trazem à tona mal-entendidos que, de outra forma, só seriam descobertos no meio da sprint — o valor está na discussão, não no número. Algumas decisões realmente precisam de um valor de custo antes de o trabalho começar, como decidir se vale a pena construir uma funcionalidade ou qual de duas propostas contratuais aceitar. E organizações que financiam o trabalho anualmente precisam de algo sobre o que basear esse financiamento.

Uma posição razoável: estime no nível em que o número muda uma decisão, e pare aí. Vale a pena produzir um tamanho aproximado para uma decisão de investimento trimestral; repontuar todos os itens em toda sessão de refinamento, em geral, não.

Planejamento de releases e capacidade

O planejamento de releases transforma previsões em uma expectativa compartilhada. As entradas são o backlog ordenado, uma faixa de previsão, as datas fixas conhecidas e a capacidade real do time — não o número de pessoas. A capacidade é reduzida por férias, plantões de suporte, reuniões, onboarding e a parte da sprint reservada para defeitos, e um time de seis raramente tem o equivalente a seis pessoas dedicadas a funcionalidades.

Mantenha nítida a distinção entre capacidade e compromisso. A revisão de 2020 do framework deixou deliberadamente de descrever o sprint backlog como um compromisso com um conjunto de itens e tornou a meta da sprint o compromisso, justamente porque a previsão tratada como promessa tinha virado o mau uso predominante. O time prevê o que espera concluir; ele se compromete com a meta.

Para uma release, apresente uma faixa com níveis de confiança, explicite as premissas e refaça a previsão a cada sprint. Quando vários times compartilham uma release, o custo de coordenação muda substancialmente o quadro — veja agilidade em escala. Quando o risco de atraso é relevante, trate-o explicitamente por meio do gerenciamento de riscos em vez de inflar as estimativas às escondidas.

Principais pontos

• Estimativas são previsões feitas no momento de maior ignorância; o cone da incerteza significa que um número único dado cedo engana e que uma faixa é honesta.
• O dimensionamento relativo funciona porque as pessoas comparam melhor do que medem em termos absolutos, e só se sustenta se o time mantiver histórias de referência.
• O planning poker existe pela conversa; uma grande dispersão de cartas significa que o escopo está sendo entendido de formas diferentes, e é justamente isso que vale descobrir.
• A velocidade é um insumo de previsão interno de cada time, expresso como faixa — compará-la entre times ou apresentá-la como produtividade a destrói.
• Contar o throughput e rodar uma simulação de Monte Carlo gera uma data probabilística com níveis de confiança a um custo recorrente quase nulo.
• Estime onde o número muda uma decisão; comprometa-se com a meta da sprint, e não com uma lista de itens, e refaça a previsão conforme chegam dados reais.