A Estimativa Mínima Útil

A maioria das equipes investe demais em precisão de estimativa. Elas debatem se um ticket é um 5 ou um 8 por dez minutos — uma distinção que não tem impacto algum no planejamento do sprint e ainda menos na entrega. O tempo gasto discutindo granularidade é tempo que não está sendo usado para entender o trabalho.

Três tamanhos — pequeno, médio, grande — cobrem a grande maioria das necessidades de planejamento. Um ticket pequeno é um trabalho bem compreendido que um desenvolvedor pode finalizar em um dia ou menos. Um médio é de um a três dias com alguma complexidade ou incógnitas. Um grande é mais de três dias e provavelmente precisa ser dividido antes de alguém começar.

É isso. Se sua equipe consegue classificar tickets nesses três grupos de forma consistente, você tem informação suficiente para planejar um sprint, identificar semanas sobrecarregadas e reconhecer tickets que precisam de mais discussão. O valor marginal de dividir "médio" em 3, 5 e 8 é real para algumas equipes — mas a maioria das equipes não precisa disso, e a complexidade custa mais do que os ganhos de precisão.

Comece com P/M/G. Se depois de alguns sprints você descobrir que seu planejamento precisa consistentemente de uma resolução mais fina — talvez os tickets grandes variem demais, ou você esteja fazendo compromissos externos que precisam de previsões mais precisas — migre para Fibonacci ou tamanhos de camiseta. Mas faça isso como uma decisão baseada em evidências, não uma decisão baseada no que um framework mandou você fazer.

P/M/G não funciona quando alguém fora da equipe precisa de mais do que "aproximadamente quanto trabalho é isso?" Três situações empurram você em direção a estimativas mais granulares:

Compromissos externos. Quando uma equipe de vendas precisa dizer a um cliente "a funcionalidade X será entregue no Q3," a equipe de desenvolvimento precisa estimar com resolução suficiente para sustentar essa data. P/M/G não consegue distinguir entre "três semanas" e "três meses." Estimativas em escala Fibonacci combinadas com dados históricos de velocidade conseguem — não perfeitamente, mas o suficiente para dar uma faixa em vez de um encolher de ombros.

Orçamento e alocação. Uma equipe de produto decidindo se financia o Projeto A ou o Projeto B precisa comparar seus custos. "O Projeto A tem 40 story points e o Projeto B tem 90" é uma entrada aproximada mas útil. "O Projeto A tem alguns médios e o Projeto B tem mais grandes" não é.

Planejamento de dependências. Quando o trabalho da Equipe A está bloqueado até a Equipe B terminar um pré-requisito, ambas as equipes precisam de precisão de estimativa suficiente para coordenar cronogramas. "Vamos terminar em algum momento nos próximos um ou dois sprints" não é suficiente quando uma equipe downstream está agendando seu trabalho em torno da entrega.

Nos três casos, o investimento em precisão se paga porque alguém está tomando uma decisão baseada na estimativa. Se ninguém está tomando uma decisão — se as estimativas vão para um rastreador e ninguém olha para elas — economize o tempo.

A maior ameaça à estimativa honesta é a ancoragem: o primeiro número dito em voz alta distorce todos os números que seguem. Se o líder técnico diz "acho que isso é cerca de 3," o desenvolvedor júnior que estava pensando em 8 questiona a si mesmo e diz 5. A equipe converge para um número que reflete a voz mais alta, não o entendimento coletivo.

Planning Poker resolve isso mecanicamente. Todos estimam simultaneamente e revelam ao mesmo tempo. Não há âncora porque não há primeiro número. A dispersão — a diferença entre a estimativa mais alta e a mais baixa — é o sinal. Um 3 unânime significa que a equipe concorda e você segue em frente. Uma divisão entre 2 e 13 significa que duas pessoas estão imaginando trabalhos fundamentalmente diferentes, e essa conversa precisa acontecer antes de alguém escrever código.

Estimativa assíncrona estende isso para equipes distribuídas. Em vez de se reunir em uma sala, os desenvolvedores enviam estimativas independentemente durante uma janela de tempo, com votos ocultos até que todos tenham enviado. O benefício anti-ancoragem é o mesmo; a logística se adapta a equipes que abrangem fusos horários ou não podem justificar reuniões síncronas para cada lote de tickets.

Ambas as abordagens compartilham o mesmo princípio: estimativa funciona melhor quando as opiniões se formam independentemente antes de serem compartilhadas. Qualquer método que permita que o número do desenvolvedor sênior influencie a sala antes que outros tenham se comprometido com sua própria estimativa está deixando informação na mesa.