Planning poker na prática

Planning poker é uma técnica de estimativa ágil feita em grupo. Cada pessoa do time recebe o mesmo baralho, ouve a história, escolhe uma carta sem mostrar e, quando todos terminam, as cartas são viradas juntas. Parece um detalhe, mas muda o tipo de conversa. Em vez de o time discutir se concorda com o número que o dev mais experiente falou primeiro, discute por que a Ana votou 2 e o Pedro votou 8. É nessa diferença que costuma estar o risco que ninguém tinha mencionado.

De onde veio a técnica

A ideia de fundo é bem mais antiga que o desenvolvimento ágil. Nos anos 1950 e 1960, a RAND Corporation criou o método Delphi: um grupo de especialistas responde a uma pergunta de forma anônima, recebe um resumo das respostas do grupo e revisa a sua em rodadas sucessivas. Na década de 1970, Barry Boehm e John Farquhar levaram o método para a estimativa de software com o nome de Wideband Delphi e acrescentaram discussão entre as rodadas.

O planning poker é uma versão enxuta dessa mesma lógica. James Grenning o descreveu num artigo curto em 2002, voltado para o planejamento de release em times ágeis. O baralho dele tinha 1, 2, 3, 5, 7, 10 e infinito. Quem espalhou a técnica foi Mike Cohn: o livro Agile Estimating and Planning, de 2005, trata dela numa seção do capítulo sobre técnicas de estimativa, e os baralhos que ele passou a vender ajudaram a fixar a sequência que virou padrão. É com planning poker que a maioria dos times dá story points às histórias do backlog.

Como é uma rodada

Uma rodada típica segue estes passos:

1. Cada pessoa tem o mesmo baralho. O padrão é a sequência de Fibonacci modificada: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, mais “?” e ☕. Por que os saltos aumentam no fim do baralho está explicado na página sobre o baralho Fibonacci.
2. A product owner (PO) apresenta a história, com o problema do usuário e os critérios de aceite.
3. O time pergunta. Regras de negócio, telas, integrações envolvidas. Desenhar a solução fica para outro momento.
4. Cada um escolhe a carta em silêncio. Sem comentários, sem caretas.
5. As cartas são reveladas de uma vez.
6. Se os votos ficaram próximos, anote o número. Com 3, 3, 5, 3, o time anota 3 sem precisar de debate.
7. Se ficaram longe, falam primeiro o voto mais alto e o mais baixo. Depois vem uma nova votação.

Votam todas as pessoas que vão construir a história, e isso inclui QA. A PO, na maioria dos times, fica de fora da votação: é ela quem pediu a funcionalidade e quem mais torce para que ela seja pequena, e o voto dela acabaria pesando como pedido de cliente. Em times Scrum, quem costuma conduzir a sessão é o Scrum Master, e o papel dele, junto com o momento certo da sprint para estimar, está na página sobre scrum poker.

Exemplo: um 3 e um 13 na mesma mesa

Um time que cuida de um app de delivery pega esta história no refinamento: “Como cliente, quero pagar o pedido com Pix para não ter que cadastrar cartão no app.”

A product owner conta que o gateway de pagamento que a empresa já usa oferece Pix, e que a ideia é mostrar a opção na tela de pagamento, com o QR code e o “copia e cola”. Alguém pergunta se o pedido vai direto para o restaurante. Ela diz que não: só depois de o pagamento cair.

Seis pessoas votam. Saem 3, 5, 3, 13, 5, 3.

O facilitador chama o Rafael, que votou 3, e a Juliana, que votou 13.

Rafael: “O gateway já faz o trabalho pesado. A gente chama a API, recebe o QR code e mostra na tela.”

Juliana: “Com cartão a resposta é na hora. Com Pix o cliente sai do app, paga no banco e volta. A confirmação chega por webhook, às vezes minutos depois. O pedido precisa de um status novo, ‘aguardando pagamento’, o QR code expira e o pedido tem que ser cancelado sozinho. E quando o restaurante recusa o pedido depois de pago, alguém tem que devolver o dinheiro por Pix.”

Metade do time não tinha pensado no pagamento assíncrono, e ninguém tinha pensado na devolução. A product owner decide na hora: na primeira versão, a devolução fica com o atendimento, que já faz isso manualmente em outros casos, e a devolução automática vira outra história.

Na segunda rodada, com a história menor, as cartas são 8, 8, 5, 8, 8, 8. O time anota 8 e deixa a história da devolução para o próximo refinamento. O status “aguardando pagamento” e o cancelamento automático quando o QR code expira entram nos critérios de aceite.

Erros comuns

Ancoragem

A âncora nem sempre é uma frase. Muitas vezes ela já está escrita no card: uma estimativa antiga de outro refinamento, um campo “prazo: sexta-feira” preenchido pelo comercial, um comentário do tipo “parecida com a história do mês passado, que foi 3”. Quem lê isso antes de votar parte daquele número e ajusta pouco. Por isso vale esconder estimativas antigas antes da sessão e deixar prazo fora da conversa até depois da revelação. Na votação em si, a revelação simultânea resolve o resto, desde que o valor de cada carta fique invisível para os outros até o fim.

O peso de quem é mais sênior

O voto secreto protege a primeira rodada, mas a pressão costuma aparecer na segunda. A pessoa júnior votou 8, viu na revelação que o tech lead jogou 3 e, na nova votação, “se convence” de que 3 está bom, sem que ninguém tenha dito nada de novo. Um combinado ajuda bastante: o tech lead fala por último, a menos que o voto dele seja um dos extremos. Aí ele explica primeiro, como qualquer voto extremo. Também ajuda o facilitador perguntar, antes da segunda rodada, se alguém mudou de ideia por um argumento concreto, e qual.

Estimar história que não está pronta

Um sinal claro de que a história não está madura é quando quase toda resposta da PO começa com “depende”. Votar nesse estado produz um número que parece sério e não se apoia em nada. Muitos times resolvem isso antes da sessão, com uma lista curta do que uma história precisa ter para ir à votação: critérios de aceite escritos, layout aprovado, contrato da API combinado com o outro time. O que fazer quando alguém joga “?” ou ☕ no meio da rodada está na página do baralho Fibonacci.

Tirar a média do desacordo

Com votos 1, 2 e 20, a média dá quase 8, um valor que ninguém escolheu e que não descreve a opinião de ninguém. Pior: um 8 no backlog apaga o fato de que alguém enxergou a história como enorme. Pergunte primeiro, faça a conta depois, se ainda fizer sentido.

Discutir sem fim

O erro oposto é passar meia hora numa história só. Uma regra que funciona bem: no máximo duas rodadas. Se depois da segunda os votos continuam espalhados, o time escolhe entre três saídas: fechar num número que todos aceitem, quebrar a história em partes menores ou adiar a estimativa até alguém trazer a informação que falta. Se nem duas conversas aproximaram os votos, falta alguma coisa que não está na sala: uma resposta do cliente, um teste rápido com a API, uma decisão de produto. Antes de passar para a próxima história, o time anota o que falta e quem vai atrás.

Planning poker com time remoto

A preparação pesa mais quando todo mundo está atrás de uma tela. Um dia antes, a PO manda no canal do time a lista de histórias da sessão, com link para cada uma, e quem tiver dúvida já pergunta por escrito. Assim a reunião começa com o texto lido e as perguntas mais óbvias respondidas.

Na chamada, o facilitador compartilha a tela com a história da vez e cola no chat o link da sala de votação. A sala mostra quem já votou, então ninguém precisa perguntar “falta alguém?”. Depois da revelação, a discussão é por voz; se for preciso votar de novo, uma nova rodada limpa as cartas. O que não funciona é votar digitando no chat do Meet ou do Teams: cada número que aparece influencia quem ainda não digitou, e combinar de apertar Enter ao mesmo tempo nunca dá certo.

O SprintPoker funciona como sala de votação no navegador, sem cadastro; a página Sobre diz o que ele tem e o que não tem.

Em sessões remotas, a atenção se perde de um jeito menos visível. Tem gente na chamada pelo celular, no meio do trânsito, e gente com o Slack piscando em outra aba. Vale combinar que quem não consegue acompanhar uma história simplesmente não vota nela, em vez de jogar qualquer carta. E sessões curtas, de uns 45 minutos, funcionam melhor que uma tarde inteira de estimativa.