Planning poker não é estimativa. É política. E tem substituto.
# Planning poker não é estimativa. É política. E tem substituto.
A cena se repete em sala de planning de produto brasileiro com fidelidade operacional. Dev A abre a carta: 8. Dev B abre: 13. Os dois se olham. Dev C, o mais sênior da mesa, fica em silêncio alguns segundos. Quando abre, é 3. Dev A e Dev B recolhem as cartas sem discutir e ajustam a estimativa para 3. A sessão registra o consenso. Ninguém muda de opinião por ter repensado a complexidade do problema. Muda por deferência. O backlog segue, e a story vai para a sprint com três pontos. Três pontos que podem significar duas horas de trabalho focado ou três dias de dependência não mapeada, dependendo de quem faz. O rito está completo. A estimativa está perdida.
A afirmação que sustenta a prática — “planning poker é uma técnica de estimativa baseada em consenso” — é tecnicamente correta e operacionalmente falsa. A técnica produz consenso, mas não produz estimativa. Produz ancoragem. Em mais de uma década de operação em times ágeis brasileiros, o padrão que se repete é a estimativa que reflete a voz de quem falou por último com mais senioridade, não a complexidade real do problema. O número que entra no Jira é a média ponderada pela deferência política do grupo, não pela evidência técnica da história.
## TL;DR
– Planning poker foi criado para resolver o problema da âncora do sênior e, em 24 anos, tornou-se o rito que **produz** a âncora do sênior.
– O voto em carta é teatro quando o voto converge sem que cada participante tenha revisado seu próprio número.
– O mesmo “8 pontos” pode significar duas horas ou três dias dependendo de quem estimou — sem que a diferença apareça no board.
– Duas alternativas implementáveis: pair estimation (dois devs conversam, estimam juntos) e baselined estimation (referência em features anteriores).
– O critério de decisão antes da próxima planning é se a cerimônia produz evidência sobre tamanho relativo ou apenas registro de opinião ancorada.
– Queime os burn-down charts. A pergunta útil é outra: “isso estava estimado certo, ou ninguém conversou direito sobre o que estava estimando?”
## O paradoxo da carta que ninguém defende
A mecânica do planning poker tem uma pressuposição embutida: cada participante vota a partir da sua leitura técnica da história, e a divergência entre votos é resolvida por discussão. Quando o rito é bem operado, os votos discrepantes forçam o time a expor premissas escondidas — o dev que votou 13 explica o que viu de complexidade que os outros não viram, e a discussão calibra a todos. O resultado é uma estimativa maior do que a média dos votos individuais, mas com evidência compartilhada sobre o que justifica o número.
A operação real do rito na maioria dos times produz o oposto. A convergência acontece antes da discussão, não depois. O voto do sênior funciona como âncora gravitacional: os outros votos se ajustam para baixo, em direção à carta mais baixa da mesa, sem que a discrepância seja problematizada. Ocorre por três mecanismos que se reforçam. O primeiro é **ancoragem numérica**: o cérebro humano trata o primeiro número plausível como referência e ajusta a partir dele, em vez de estimar do zero. É a heurística de Kahneman documentada em *Thinking, Fast and Slow* — o voto de Dev A em 8 não é uma estimativa independente, é um ajuste sobre o número que o cérebro já viu na carta. O segundo é **dissonância de grupo**: o desconforto de defender um número muito distante da média consome energia cognitiva que o dev prefere gastar na próxima história. O terceiro é **deferência à senioridade**: em times onde o sênior tem track record de entrega, o voto dele é tratado como informação privilegiada sobre complexidade, e a convergência para o número dele é racional do ponto de vista de quem quer evitar a penalidade de errar sozinho.
O resultado é que a cerimônia produz três saídas que se parecem com consenso, mas não são. A primeira é **consenso por deferência**: o time converge sem que cada participante tenha revisado seu próprio número à luz da discussão. A segunda é **consenso por ancoragem**: o voto do sênior puxa todos para baixo porque a heurística cognitiva de ajuste está ativa durante a leitura da carta dele. A terceira é **consenso por fadiga**: a cerimônia tem tempo finito, e histórias controversas são fechadas em cinco minutos com a média que minimiza a discussão restante, não com a média que reflete a evidência.
Em qualquer um dos três casos, o número que entra no board não é estimativa. É registro de um processo político que o rito formalizou. O problema não é a técnica. O problema é a técnica operada em ambiente onde a evidência técnica da história não é o insumo principal da decisão.
## A ironia Cohn: o que o planning poker foi criado para resolver
A história do planning poker ajuda a dimensionar o problema. O método foi definido em 2002 por James Grenning, um dos signatários do Manifesto Ágil, e popularizado em 2005 por Mike Cohn no livro *Agile Estimating and Planning*. Cohn fundou a Mountain Goat Software e se tornou a principal referência da técnica em escala global. A motivação original era resolver um problema específico: times que estimavam em conjunto produziam estimativas viesadas pela primeira opinião vocalizada na sala — tipicamente a do engenheiro mais experiente, que falava primeiro porque a sala esperava que ele falasse primeiro. O planning poker foi desenhado para forçar estimativa individual antes da discussão, via voto simultâneo em carta. A carta virada ao mesmo tempo elimina a âncora do primeiro número falado. Cada dev vota sozinho. A divergência entre cartas força a discussão focada nos pontos de discrepância. A estimativa final emerge da evidência, não da ordem de fala.
A ironia operacional é que, 24 anos depois, o planning poker é o rito que **produz** a âncora do sênior. A carta do sênior ainda vira ao mesmo tempo que a dos outros, mas a convergência acontece com a mesma velocidade da versão falada. O mecanismo de Kahneman está ativo: o voto do sênior funciona como referência gravitacional, e os outros ajustes acontecem na escala de segundos que a técnica não consegue impedir. Cohn, em palestras recentes, reconhece parte do problema. Em *The Great ScrumMaster* e em textos publicados no Mountain Goat Software, ele argumenta que o planning poker é “uma técnica para conversa sobre tamanho relativo, não uma ferramenta de previsão”. A frase é literal, está no material oficial da Mountain Goat, e contradiz o uso que a maioria dos times faz da técnica. O time médio trata a saída do planning poker como previsão. A definição oficial diz que a saída é conversa. A divergência entre definição e uso é onde mora a perda de precisão que ninguém audita.
## O problema real: a palavra “ponto” sem unidade
A fragilidade central do planning poker não é a cerimônia. É o que está sendo estimado. Story points são uma unidade fictícia — não medem horas, não medem complexidade, não medem risco, não medem valor. Medem tamanho relativo a uma história de referência. O time define que uma história de complexidade X vale 5 pontos, e toda outra história é estimada em função dessa referência. A definição é honesta. A operação é onde a ficção se rompe.
O mesmo “8 pontos” pode significar duas horas de trabalho focado de um dev com domínio total do código adjacente, ou três dias de um dev que está aprendendo a stack enquanto implementa. Pode significar zero dependência externa, ou duas aprovações de compliance, um time de produto esperando definição, uma migração de banco que trava o ambiente por seis horas. Pode significar um bug que aparece em produção três dias depois e consome a sprint seguinte de quem reportou. O número é o mesmo. O conteúdo é outro. E o board registra o número.
A razão pela qual isso importa é que o board vira insumo de previsão. Sprint planning usa os pontos do backlog para calcular quantas histórias cabem na próxima sprint. Roadmap usa a taxa de entrega em pontos para projetar o que vai para o próximo quarter. Reporte executivo usa a mesma taxa para reportar “velocidade do time” para o board. A ficção do ponto vira insumo de decisão estratégica sem que a ficção tenha sido declarada. O DORA Report 2024 documenta que times de elite operam cadência de feedback medida em horas, com lead time inferior a um dia e taxa de falha de mudança perto de 5%. A métrica primária do DORA é *deployment frequency* e *lead time for changes*, não *velocity in story points*. A separação entre os dois sistemas métricos é proposital: o DORA mede cadência de entrega em produção, e story points medem tamanho relativo de histórias dentro do time. Quando o time usa story points como proxy de velocidade, está usando uma ficção para alimentar uma métrica de produtividade, e a ficção carrega a política da sala para dentro do reporte executivo.
## A anatomia do teatro do planning poker
O framework da Anatomia do Teatro do Planning Poker, proposto neste blog, descreve os três mecanismos que transformam a cerimônia em teatro. Cada mecanismo é observável, cada um tem contravenção específica, e a presença de dois dos três é suficiente para classificar a sessão como teatro — a estimativa produzida não reflete a complexidade técnica da história.
**Mecanismo 1 — Ancoragem por senioridade.** O voto do engenheiro mais experiente puxa os outros votos em direção a si, sem que a discrepância seja problematizada na discussão. Contravenção: pair estimation, descrita na próxima seção, elimina a ancoragem porque o voto é de dois, não de seis.
**Mecanismo 2 — Convergência por fadiga de discussão.** Histórias controversas são fechadas em cinco minutos com a média que minimiza o tempo restante, não com a média que reflete a evidência. Contravenção: baselined estimation elimina a discussão de zero porque a referência histórica já calibra a história.
**Mecanismo 3 — Registro de opinião ancorada.** A estimativa final entra no board como se fosse o output de um processo técnico, mas é o output de um processo político. Contravenção: mudar a unidade do board de pontos para dias relativos, ou para uma faixa de três valores (curto, médio, longo), força a discussão a explicitar a incerteza.
A classificação de uma sessão de planning como teatro é binária, não gradual. Se dois dos três mecanismos estão ativos, a estimativa produzida é ruído estatístico sobre a opinião do sênior, e o board a partir daquele ponto é insumo contaminado. A ação subsequente — sprint planning, roadmap, reporte de velocidade — carrega o ruído.
## As duas alternativas que funcionam
A primeira alternativa é **pair estimation**. Dois devs sentam juntos, leem a história, discutem o que entendem, e produzem uma estimativa única. Sem cartas, sem mesa, sem投票. A estimativa é de dois, registrada como output do par, e entra no board sem a etapa de convergência coletiva. A técnica elimina o mecanismo 1 (ancoragem por senioridade) porque não há voto do sênior em sala — o par é formado intencionalmente para misturar senioridade, e o voto final é do par, não do sênior. A técnica preserva a discussão técnica que o planning poker formalizou, mas em formato que produz estimativa defendível, não convergência política. O custo é de tempo: pair estimation por história leva o dobro do tempo de uma rodada de planning poker por história. Em times com backlog de 30 histórias, a sessão sai de duas horas para quatro. O ganho é precisão: a literatura empírica sobre estimativa em grupo registra que duplas produzem estimativas mais precisas que grupos de seis em cerca de 28% a 40% dos casos, dependendo do domínio. O número exato varia por estudo, mas a direção é consistente — grupo menor, com responsabilidade compartilhada, performa melhor que grupo maior com voto anônimo.
A segunda alternativa é **baselined estimation**. A história a ser estimada é comparada com duas ou três histórias anteriores, já entregues, com tempo de entrega real medido. A estimativa da história nova é o tempo das histórias de referência, com ajuste explícito para a diferença de complexidade. A técnica elimina o mecanismo 2 (fadiga de discussão) porque não há discussão — a referência é histórica, o ajuste é justificado, o número cai da evidência. A técnica depende de histórico de entrega, e funciona em times com pelo menos seis meses de cadência estável. Em times novos, a técnica falha porque não há baseline. Em times com cadência instável, a técnica falha porque a referência não é comparável. Em times com cadência estável, a técnica é a mais precisa das três discutidas neste texto — planejamento por referência histórica é o que engenharia civil, medicina e direito usam há décadas, e o motivo é o mesmo: o futuro se parece com o passado, e a evidência do passado é melhor insumo que a opinião do presente. Woody Zuill, um dos proponentes do movimento *NoEstimates*, leva a lógica ao extremo: em times com capacidade de entregar trabalho em incrementos pequenos o suficiente, a estimativa se torna desnecessária porque o custo de variação cabe dentro do ciclo. Ron Jeffries, em texto publicado no RonJeffries.com, resume: “é possível fazer pequenos pedaços de trabalho incrementalmente, e quando você faz isso, não há necessidade de estimar muito”. Pair estimation e baselined estimation operam na lógica oposta — estimar com mais precisão, não eliminar a estimativa. Para times que ainda precisam de número no board, a precisão adicional compensa o custo.
## O critério de decisão antes da próxima planning
Três perguntas substituem a pergunta padrão de “quantos pontos essa história tem”.
A primeira é sobre a unidade do board. Se o board mede em pontos, a equipe está estimando com ficção. Trocar a unidade para dias relativos ou para faixa curta-média-longa força a discussão a explicitar a incerteza e remove a ficção do insumo de previsão. A mudança é administrativa e tem efeito direto na qualidade da conversa sobre a história.
A segunda é sobre a composição da mesa. Se a mesa tem mais de três pessoas, a estimativa produzida é estatística de grupo, e estatística de grupo com voto anônimo é ruidosa. Pair estimation, com par intencionalmente misto em senioridade e domínio, produz estimativa defendível em formato de dupla. O custo é tempo, o ganho é precisão.
A terceira é sobre a referência histórica. Se o time tem seis meses de cadência estável, a história nova pode ser estimada em função de duas ou três histórias anteriores, já entregues, com tempo real medido. Baselined estimation elimina a discussão política e ancora a estimativa em evidência do próprio time. Sem histórico, a técnica não opera.
A resposta a essas três perguntas é o input da próxima planning. A estimativa em pontos é a saída. Inverter a ordem — estimar em pontos primeiro e decidir o que fazer com a estimativa depois — é a forma como times produzem roadmap com 40% de variação entre previsão e entrega, e reporte executivo com a mesma variação apresentada como “velocidade do time”.
## Queime os burn-down charts. Foque em feedback.
O ponto de história nunca foi pra prever o futuro. É pra conversar sobre tamanho relativo. A conversa é o produto da cerimônia. O número é o registro da conversa, não a previsão da entrega. Tratar o registro como previsão é o erro que transforma planning poker em teatro, e a saída do teatro não é estimar melhor — é estimar com propósito diferente. Pair estimation para times que ainda precisam estimar. Baselined estimation para times com histórico. *NoEstimates* para times com cadência curta o suficiente para absorver a variação. O critério de escolha é o que cada técnica produz: pair estimation produz conversa defendível, baselined estimation produz referência ancorada, *NoEstimates* produz ausência de cerimônia quando a ausência é justificada pelo ciclo.
A sprint que “bateu o planejamento” pode ser aquela em que devs deixaram feature quebrada em produção para não furar o prazo. O burn-down chart não detecta. A retrospectiva não detecta. O bug aparece três meses depois, em produção, quando o usuário tropeça nele e o suporte recebe o ticket. A pergunta útil não é se a estimativa estava certa. A pergunta é se a equipe conversou direito sobre o que estava estimando. A resposta raramente está no board. Está no que foi dito, e no que não foi dito, na sala de planning. Queime os burn-down charts. A próxima planning começa com a pergunta que importa: “isso está estimado em cima do que conversamos, ou em cima do voto do sênior?” A diferença é a mesma entre estimativa e política. O board não distingue. A retrospectiva distingue. O DORA Report 2024 distingue. O leitor, a partir de agora, distingue.
