Postagens
O que é planning poker?

Matt Lewandowski
Última atualização 21/06/20267 min de leitura
Também conhecida como
Scrum poker, estimation poker, pointing poker
Introduzida por
James Grenning em 2002, depois popularizada por Mike Cohn
Usada para
Estimar o esforço relativo de itens do backlog
Ideal para
Planejamento de sprint e refinamento de backlog com 3 a 9 pessoas
Como funciona o planning poker
Apresente o item
O product owner lê um item do backlog em voz alta e responde a quaisquer perguntas rápidas sobre escopo e critérios de aceitação. Cada um escolhe uma carta em segredo
Cada pessoa escolhe a carta que corresponde ao esforço que espera, com base na complexidade, nas incertezas e no risco. Sem espiar os outros. Revelem ao mesmo tempo
Todas as cartas viram juntas. Como ninguém viu as dos outros antes, a variação reflete o que as pessoas realmente pensam. Discutam os extremos
Quem votou mais alto e quem votou mais baixo explicam seu raciocínio. É aqui que você descobre uma dependência esquecida ou um requisito que as pessoas entenderam de formas diferentes. Votem de novo até convergir
Votem novamente com o novo contexto. A maioria dos itens se resolve em uma ou duas rodadas. O objetivo é chegar perto o suficiente, não à unanimidade.

As cartas: qual baralho você deve usar?
| Baralho | Valores | Ideal para |
|---|---|---|
| Fibonacci | 1, 2, 3, 5, 8, 13, 21 | O padrão para a maioria dos times de software |
| Fibonacci modificado | 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100 | Acrescenta espaço para "trivial" e "grande demais para estimar" |
| Tamanhos de camiseta | PP, P, M, G, GG | Dimensionamento inicial de roadmap e stakeholders não técnicos |
| Potências de dois | 1, 2, 4, 8, 16 | Times que preferem uma escala limpa de duplicação |
| Personalizado | O que você quiser | Dias ideais, horas ou seus próprios rótulos |
Por que os times usam
🎴Elimina o viés de ancoragem
💡Revela suposições ocultas
🙋Traz as vozes mais quietas
⚡Rápido e repetível

Quando o planning poker funciona, e quando não
- Você está dimensionando itens para uma sprint futura e quer entendimento compartilhado
- O time tem de 3 a 9 pessoas que farão o trabalho
- Os requisitos estão claros o suficiente para discutir, mas ainda têm incertezas
- Você tem mais de 50 itens e pouco tempo. Use mapeamento por afinidade ou o sistema de baldes no lugar
- O trabalho é totalmente compreendido e rotineiro. Apenas atribua um tamanho
- Uma pessoa já sabe exatamente como construir e ninguém mais vai mexer nisso
Conduzindo sua primeira sessão
Escolha uma base de comparação
Escolha uma história pequena e bem compreendida com que todos concordem e chame-a de sua referência. A prática comum é torná-la um 2 ou 3, não um 1, para que você tenha espaço para descer mais. Traga as pessoas certas
Convide quem vai construir o trabalho: desenvolvedores, QA e um product owner para responder a perguntas sobre escopo. Mantenha o grupo enxuto. Defina um tempo limite por item
Dê alguns minutos a cada rodada. Se ainda estiverem divididos após duas votações, anote a pergunta em aberto, divida a história ou deixe-a para o refinamento. Registre a estimativa e siga em frente
Registre o tamanho acordado e mantenha o ritmo. A estimativa tem retornos decrescentes acentuados assim que você chega perto o suficiente.