Horas vs. Tamanhos vs. Contagens

Humanos são ruins em estimar tempo absoluto, e engenheiros não são exceção. Pesquisas sobre a falácia do planejamento — a tendência sistemática de subestimar quanto tempo as tarefas levarão — mostram consistentemente que as pessoas subestimam por um fator de 2 a 4, mesmo para tarefas que já fizeram antes. O problema não é preguiça ou incompetência. O problema é cognitivo: quando você imagina fazer uma tarefa, você imagina o caminho feliz. Você não imagina a suíte de testes instável, os critérios de aceitação pouco claros, a dependência que foi atualizada na semana passada ou as duas horas que você passará em reuniões.

Horas também convidam ao viés de ancoragem. Uma vez que alguém diz "isso provavelmente leva umas 4 horas", toda estimativa subsequente orbita em torno de 4. Se a primeira pessoa tivesse dito 12, o grupo teria convergido em um número diferente — não porque o trabalho mudou, mas porque a âncora mudou. Horas parecem precisas de uma forma que convida à falsa confiança. "Esta é uma tarefa de 6 horas" parece um fato. É um palpite vestindo um jaleco.

A solução não é "melhorar na estimativa de horas". Décadas de evidência dizem que isso não funciona. A solução é parar de usar uma unidade de medida que desencadeia a falácia do planejamento em primeiro lugar e mudar para algo relativo.

A estimativa relativa contorna a falácia do planejamento perguntando "quão grande é isso comparado a algo que já fizemos?" em vez de "quantas horas isso levará?" Você não está prevendo o futuro — você está comparando.

As escalas mais comuns são tamanhos de camiseta (P, M, G, GG) e números estilo Fibonacci (1, 2, 3, 5, 8, 13). Ambas funcionam porque são deliberadamente imprecisas. Não há diferença significativa entre um 6 e um 7, então a escala não oferece essas opções. Fibonacci força você a entrar em categorias, e as lacunas entre as categorias crescem à medida que os números ficam maiores — o que corresponde à realidade. A diferença entre um 1 e um 2 é significativa. A diferença entre um 13 e um 15 é ruído.

A chave para fazer a estimativa relativa funcionar são as histórias de referência. Escolha dois ou três tickets concluídos que toda a equipe se lembra e atribua tamanhos a eles: "o redesign da página de login foi um 5, a correção da exportação CSV foi um 2, a integração de pagamento foi um 13". Agora cada novo ticket é comparado a essas referências, não a uma escala de tempo abstrata. "Isso é mais parecido com a correção CSV ou mais parecido com o redesign de login?" é uma pergunta que engenheiros podem responder com confiança. "Quantas horas isso levará?" é uma pergunta que eles errarão.

O método de estimativa mais simples é nenhuma estimativa — apenas conte tickets. Se sua equipe completa cerca de 12 tickets por sprint, e o backlog tem 15 tickets no próximo sprint, você sabe que está sobrecarregado sem estimar um único.

Contar funciona quando os tickets são aproximadamente do mesmo tamanho, o que significa que funciona quando as equipes são disciplinadas quanto à divisão. Um ticket que diz "construir todo o sistema de notificações" e um ticket que diz "adicionar uma verificação de nulo ao endpoint de exportação" não são unidades comparáveis. Mas uma equipe que escreve consistentemente tickets dimensionados em meio dia a dois dias de trabalho — onde o maior ticket é no máximo 3–4 vezes o menor — pode usar a contagem de tickets como um proxy confiável para capacidade.

A disciplina que isso requer é a divisão de histórias: quebrar o trabalho em pedaços pequenos o suficiente para que a variação de tamanho seja baixa. Isso não é de graça. Mas tem um benefício colateral que pode ser mais valioso do que a própria estimativa — tickets pequenos e bem definidos são mais fáceis de revisar, mais fáceis de testar e menos propensos a ficar "em progresso" por uma semana. O método de estimativa recompensa exatamente o comportamento que você deseja da equipe de qualquer forma.