Planning poker é uma técnica de estimativa em que cada pessoa do time escolhe em particular uma carta representando o esforço, e todos revelam ao mesmo tempo. O consenso vem da conversa sobre as diferenças, não da média.
A revelação simultânea é o mecanismo inteiro. Se os números são ditos um por vez, o primeiro ancora todos os seguintes, e a estimativa acaba medindo senioridade em vez de complexidade. Quando a mesa vira junta, não há âncora.
Quando as cartas divergem, quem votou mais alto e quem votou mais baixo explicam o que estão vendo. Essa conversa — e não a aritmética — é o valor do método: ela traz à tona suposições não ditas e critérios de aceitação faltando, antes do sprint e não no meio dele.
James Grenning descreveu a técnica em 2002, quando uma reunião de estimativa saiu do controle. O livro “Agile Estimating and Planning”, de Mike Cohn, colocou o nome planning poker diante de quase toda a indústria três anos depois. O Guia do Scrum não exige nada disso: ele só diz que os Developers dimensionam o trabalho. Planning poker é, portanto, uma convenção muito difundida que combina bem com Scrum, não uma regra que você quebra ao estimar de outro jeito.
O nome vem das cartas e da revelação conjunta, não de apostas. Cada pessoa tem uma mão de cartas numeradas, joga uma virada para baixo, e a mesa inteira vira junta. Nada é apostado e não há vencedor.
Uma estimativa em horas promete uma precisão que ninguém tem no momento de estimar.
Sempre igual, presencial ou remoto.
Planning poker é uma técnica de estimativa para times ágeis: cada pessoa escolhe em particular uma carta com um número que representa o esforço de uma tarefa, e depois todos revelam ao mesmo tempo. Onde os números divergem, conversa-se rapidamente e vota-se de novo, até o time concordar. Escolher em particular evita que todos se orientem pelo primeiro número dito.
O Product Owner apresenta o item e responde perguntas. Todos que vão fazer o trabalho escolhem uma carta em particular. Todas são reveladas ao mesmo tempo. Se estiverem próximas, registra-se o número. Se não, quem votou mais alto e quem votou mais baixo explicam, e vota-se de novo. Com prática, cada item leva um ou dois minutos.
Todos que vão fazer o trabalho: desenvolvimento, QA e qualquer outra pessoa envolvida. O Product Owner responde perguntas sobre a intenção, mas normalmente não vota. O Scrum Master facilita e fica fora da votação, para observar a dispersão em vez de aumentá-la.
Na maioria das vezes a sequência de Fibonacci: 1, 2, 3, 5, 8, 13, 21 e 34, quase sempre com uma carta ? para “assim eu não consigo estimar”. Os saltos crescem de propósito, porque a incerteza cresce com o tamanho. Tamanhos de camiseta (XS a XXL) e potências de 2 são alternativas comuns e funcionam igual.
Peça a quem votou mais alto e a quem votou mais baixo que expliquem o que estão vendo: quase sempre estão olhando para trabalhos diferentes. Depois votem de novo. Se uma segunda rodada ainda dividir a mesa, a história costuma estar vaga ou grande demais, e quebrá-la é melhor do que aceitar um número do meio em que ninguém acredita.