Como fazer planning poker (passo a passo)

Planning poker é uma técnica de estimativa por consenso em que cada pessoa do time escolhe, de forma privada, uma carta para o esforço de uma tarefa, todos revelam ao mesmo tempo e o time discute qualquer divergência até convergir para uma estimativa compartilhada. É a técnica de julgamento de especialista mais usada na pesquisa sobre estimativa ágil. Para fazer, você precisa de um time, uma lista de itens para estimar e um deck de estimativa, e então segue os sete passos abaixo.

O que é planning poker?

Planning poker (também chamado de scrum poker ou pointing poker) transforma a estimativa em um jogo curto e estruturado. Em vez de a pessoa mais experiente ou mais falante definir o número, todos se comprometem com uma estimativa em privado e revelam de uma vez. Essa única regra, a revelação simultânea, é o que faz a técnica funcionar.

Por que funciona: a ciência de estimar em grupo

A razão de o planning poker revelar as cartas simultaneamente é evitar a ancoragem (anchoring), o viés bem documentado em que o primeiro número mencionado puxa a estimativa de todos na sua direção. Em experimentos controlados, só de mostrar um número qualquer a profissionais de software antes de eles estimarem já puxava as estimativas fortemente naquela direção. O efeito foi grande, e um workshop de treinamento criado para combatê-lo apenas suavizou a atração, sem eliminá-la. A ancoragem é apontada há muito tempo como uma causa importante de estimativas de software que saem baixas demais.

Estimar em grupo também ajuda. Em um estudo que acrescentou planning poker a tarefas de um projeto real, a estimativa que o time acordou depois de discutir ficou menos otimista do que simplesmente tirar a média dos palpites individuais, e acabou mais perto do esforço real. (Referências completas em Fontes, abaixo.)

O que você precisa antes de começar

• Um time com as pessoas que vão fazer o trabalho (normalmente de 3 a 9).
• Uma lista priorizada de histórias de usuário ou tarefas para estimar.
• Um deck de estimativa (ver passo 2).
• Um facilitador (geralmente o Scrum Master) e alguém que possa responder dúvidas sobre cada item (geralmente o Product Owner).

Como fazer planning poker: 7 passos

1. Crie a sala e convide o time. Crie uma sessão e compartilhe o link. Com o Planning Poker Web, qualquer pessoa pode entrar sem criar conta: abre o link e já está dentro. Dica de facilitação: combine o deck e uma história de referência ("este bug pequeno = 2 pontos") antes de começar, para todos calibrarem na mesma escala.
2. Escolha um deck de estimativa. Defina a escala com que o time vai votar (Fibonacci, tamanhos de camiseta, e por aí vai). Dica: mantenha o mesmo deck entre as sprints para a sua velocidade continuar comparável.
3. Apresente a primeira história. O Product Owner lê o item e responde às dúvidas. Seja breve, porque o detalhe aparece na discussão. Tempo sugerido: cerca de 2 minutos de apresentação.
4. Todos votam ao mesmo tempo. Cada pessoa seleciona em privado a carta que corresponde à sua percepção do esforço. Nenhum número é falado em voz alta ainda. Dica: inclua todos que fazem o trabalho (testers e designers, não só quem programa).
5. Revelem as cartas juntos. Quando todos tiverem votado, revelem simultaneamente. Este é o passo anti-ancoragem: nenhum voto foi influenciado pelo de outra pessoa.
6. Discutam as divergências. Se as estimativas diferem, quem votou mais alto e mais baixo explica o raciocínio. Isso traz à tona premissas escondidas, tarefas esquecidas e riscos, muitas vezes a parte mais valiosa da sessão. Tempo sugerido: cerca de 3 a 5 minutos. Se passar muito disso, a história provavelmente está grande demais.
7. Votem de novo até convergir. Vote outra vez após a discussão. Repita até o time chegar a um número compartilhado. Registre e siga para o próximo item. Dica: "convergir" significa perto o suficiente para concordar, não idêntico, então não persiga uma carta unânime.

Um exemplo prático: estimando uma história

Digamos que a história seja "O usuário pode redefinir a senha por e-mail". O Product Owner lê, e um tester pergunta se limitar tentativas (rate-limiting) está no escopo (está). O time vota com um deck Fibonacci e revela:

O tester (8) explica: o fluxo de redefinição precisa de rate-limiting, trabalho no template de e-mail e casos de borda para tokens expirados, nada disso imaginado pelos outros. É exatamente o trabalho escondido que o planning poker existe para revelar. Após a discussão o time vota de novo (5, 5, 8, 5) e concorda em 5. O número importa menos do que o fato de o time inteiro agora compartilhar a mesma imagem do trabalho.

Planning poker remoto vs. presencial

A mecânica é idêntica. A facilitação muda.

• Presencial: cartas físicas funcionam, mas alguém precisa transcrever os resultados e não há histórico automático. Fique atento a pessoas que revelam devagar e influenciam as outras.
• Remoto ou distribuído: uma sala online compartilhada é essencial. A revelação é garantida pela ferramenta (ninguém vê os votos antes da hora), resultados e histórico são capturados automaticamente, e o voto assíncrono permite que times em fusos diferentes estimem sem uma call ao vivo. É aqui que uma ferramenta como o Planning Poker Web substitui o baralho físico por completo. Veja nosso guia de planning poker para times remotos para montagens ao vivo e assíncronas.

Quando NÃO usar planning poker

Planning poker nem sempre é a ferramenta certa. Pule, ou escolha algo mais rápido, quando:

• O backlog é enorme (50+ itens). Votar item por item é lento demais. Use estimativa por afinidade ou o sistema de baldes para uma primeira passada, e então planning poker só nos itens incertos.
• Uma pessoa claramente é dona do trabalho. Sem diversidade de perspectivas, o ritual em grupo acrescenta pouco a uma estimativa rápida de especialista.
• O time já compartilha um modelo mental claro. Para trabalho bem conhecido e repetitivo, as estimativas raramente divergem, então a discussão tem pouco a revelar.
• Você está estimando um roadmap de longo prazo, não uma sprint. Um dimensionamento grosseiro (tamanhos de camiseta) já basta, e pontos relativos precisos são esforço desperdiçado tão cedo.

Ser honesto sobre isso gera confiança. Forçar planning poker na situação errada é como os times passam a detestar estimativa.

Cenários difíceis (e como lidar com eles)

• O time não converge após duas rodadas. A história geralmente está grande ou vaga demais. Quebre-a, ou devolva ao Product Owner para esclarecer.
• Uma pessoa domina a discussão. O voto privado já limita isso. Reforce pedindo para quem votou mais baixo falar primeiro, não a pessoa mais sênior.
• Alguém sempre vota com a maioria. Peça que vote antes de "ler a sala". Em uma ferramenta, os votos ficam ocultos até a revelação, o que tira a tentação.
• As estimativas ficam consistentemente baixas. É o otimismo e a ancoragem agindo. Mantenha uma história de referência visível e compare os novos itens com ela, em vez de estimar no vácuo.

Planning poker vs. outras técnicas de estimativa

Erros comuns a evitar

• Falar um número antes da revelação, o que reintroduz a ancoragem.
• Estimar em horas em vez de pontos relativos. O dimensionamento relativo é mais rápido e menos enviesado.
• Tirar a média em vez de discutir. A discussão é o ponto, e o número é o subproduto.
• Deixar uma pessoa dominar. O voto privado existe justamente para evitar isso.
• Votar para sempre. Perseguir uma carta unânime desperdiça tempo, então "perto o suficiente para concordar" é o objetivo.

Glossário: termos do planning poker

• Story point (ponto de história): uma unidade de esforço relativo (não horas), que combina complexidade, incerteza e volume de trabalho.
• Deck: o conjunto de cartas com que o time vota (ex.: Fibonacci, tamanhos de camiseta).
• Velocidade (velocity): quantos pontos um time conclui por sprint, usado para prever, não para comparar times.
• Ancoragem (anchoring): o viés em que o primeiro número mencionado puxa as outras estimativas na sua direção, a razão de os votos serem revelados ao mesmo tempo.
• Divergência (outlier): o voto mais alto ou mais baixo, cujo raciocínio o time discute primeiro.
• História de referência: um item já estimado com que o time compara as novas histórias, para manter a escala estável.

Perguntas frequentes

Quanto tempo dura uma sessão de planning poker?

Para um backlog normal de sprint, de 30 a 60 minutos. Um único item costuma levar de 1 a 3 minutos, a menos que as estimativas divirjam e precisem de discussão.

Quantas pessoas devem participar?

Normalmente as 3 a 9 pessoas que de fato vão fazer o trabalho. Menos de três perde o benefício de visões diversas, e mais de nove deixa a discussão lenta.

Qual deck devemos usar?

Fibonacci (0, 1, 2, 3, 5, 8, 13 em diante) é o padrão mais comum, porque os intervalos crescentes refletem a incerteza maior em itens grandes. Tamanhos de camiseta servem para um dimensionamento inicial e grosseiro.

Por que todas as cartas são reveladas ao mesmo tempo?

Para evitar a ancoragem, o viés em que o primeiro número falado puxa a estimativa de todos na sua direção. A revelação simultânea mantém cada voto independente.

Estimamos em horas ou em pontos?

Pontos relativos (story points) são recomendados. São mais rápidos de acordar e menos sujeitos ao viés otimista que as estimativas em horas mostram na pesquisa.

E se o time não chegar a um acordo?

Deixe quem votou mais alto e mais baixo explicar, e votem de novo. Se ainda não convergir, o item provavelmente está grande ou vago demais, então quebre-o ou devolva para esclarecer.

Dá para fazer planning poker de forma assíncrona?

Sim. Com uma ferramenta online, as pessoas votam no próprio tempo e a revelação acontece quando todos tiverem votado, o que é útil para times distribuídos em fusos diferentes. O benefício anti-ancoragem continua valendo, porque os votos ficam ocultos até a revelação.

Quem deve participar, e o Scrum Master vota?

Todos que fazem o trabalho (devs, testers, designers). O Scrum Master normalmente facilita em vez de votar, e o Product Owner responde dúvidas mas não estima.

Planning poker é o mesmo que scrum poker?

Sim. "Scrum poker" e "pointing poker" são sinônimos comuns para a mesma técnica.

Fontes

1. Moløkken-Østvold, Haugen & Benestad (2008). Using planning poker for combining expert estimates in software projects. Journal of Systems and Software, 81(12), 2106 a 2117.
2. Mahnič & Hovelja (2012). On using planning poker for estimating user stories. Journal of Systems and Software, 85(9), 2086 a 2095.
3. Jørgensen & Sjøberg (2001). Anchoring effects: an important cause of too optimistic effort estimates. Simula.
4. Løhre & Jørgensen (2016). Numerical anchors and their strong effects on software development effort estimates. Journal of Systems and Software.
5. Shepperd et al. (2018). An Experimental Evaluation of a De-biasing Intervention for Professional Software Developers. arXiv:1804.03919.