Como conduzir o Planning Poker passo a passo

O Planning Poker funciona quando as cartas promovem uma conversa útil — não quando o time tenta adivinhar o número “correto”. Uma boa sessão oferece a todos o mesmo contexto do backlog, protege o julgamento independente até a revelação e usa estimativas diversas para revelar pressupostos antes do trabalho entrar em um sprint.

Este guia oferece uma agenda repetível para um facilitador, um Product Owner ou responsável pelo backlog e as pessoas que ajudarão a entregar o trabalho.

Neste guia

• A versão resumida
• Prepare o backlog e os participantes
• Use uma agenda prática de 45 minutos
• Calibre e apresente cada item
• Vote, revele e discuta a variação
• Revote, divida ou pause
• Revise o exemplo de cinco itens
• Evite erros comuns
• Use a lista de verificação do facilitador

A versão resumida

Para cada item do backlog:

1. Explique o resultado para o usuário, o escopo e as condições de aceitação.
2. Permita que o time faça perguntas para esclarecimento.
3. Peça que cada estimador escolha uma carta em sigilo.
4. Revele todas as cartas simultaneamente.
5. Se a variação for significativa, ouça os motivos dos votos mais baixo e mais alto.
6. Esclareça o item, divida-o quando necessário e vote novamente.
7. Registre a estimativa acordada pelo time e siga para o próximo item.

Planning Poker é uma prática de estimativa, não um evento obrigatório do Scrum. O guia atual do Scrum deixa os métodos de dimensionamento a critério do time, enquanto reforça que as pessoas que executam o trabalho são responsáveis por estimar os itens do Product Backlog.

Antes da sessão: prepare o trabalho que será discutido

Uma sala de votação não compensa um item do backlog que ninguém compreende. Prepare um conjunto pequeno de itens próximos a serem feitos, em vez de trazer o backlog inteiro.

Para cada item, certifique-se de que o time possa ver:

• o resultado para o usuário ou negócio;
• o que está incluído e explicitamente excluído;
• condições de aceitação ou exemplo de comportamento esperado;
• dependências, restrições e sistemas afetados conhecidos;
• perguntas em aberto que podem alterar o tamanho;
• um link para designs de suporte ou contexto técnico, quando relevante.

Não elimine toda incerteza antes da estimativa. A incerteza faz parte do que a estimativa deve revelar. Mas o time precisa de contexto suficiente para distinguir um detalhe pequeno de implementação de uma decisão de produto não resolvida.

Escolha uma escala antes de iniciar a votação

Muitos times usam uma sequência parecida com Fibonacci, como 1, 2, 3, 5, 8, 13, 21. Os intervalos crescentes refletem que a confiança geralmente diminui conforme o trabalho fica maior ou menos compreendido. O Agilo também suporta outras escalas embutidas e conjuntos de cartas personalizados.

Considere os story points como tamanhos relativos específicos do time. Um 5 é útil porque o time entende como ele se compara com seu próprio 2 ou 8; não é uma quantidade universal de horas e não deve ser copiado entre times como uma tabela de conversão.

Convide as pessoas certas

As pessoas esperadas para realizar o trabalho devem votar. O Product Owner ou responsável pelo backlog explica a intenção, prioridade e concessões. Um facilitador mantém o ritmo, abre espaço para participantes mais silenciosos e evita que a discussão vire uma negociação em busca de um número preferido.

No Agilo, os participantes precisam de contas para entrar em uma sala e votar. Crie a sala antes da sessão, selecione o sistema de estimativa, adicione ou importe os primeiros itens e envie o convite com tempo suficiente para todos participarem.

Interface atual do Agilo: oito participantes fictícios votaram, enquanto todas as estimativas permanecem ocultas até a revelação.

Uma agenda prática de 45 minutos

Use isto como ponto de partida e ajuste conforme o número e a complexidade dos itens.

Cinco itens bem preparados são frequentemente mais úteis que quinze votos apressados. Se o time precisar repetidamente de longas descobertas do produto durante a sessão, devolva esses itens para refinamento e mantenha o Planning Poker focado em trabalho pronto para a conversa de dimensionamento.

Passo 1: calibre com uma referência conhecida

Comece com um item recém-concluído cuja forma o time se lembre. Você não está reescrevendo a história para produzir uma nota perfeita. Está oferecendo à sala uma comparação compartilhada: “Este item teve uma alteração na interface, uma alteração na API e cobertura de teste conhecida; para nós representa um 3.”

Use referências do mesmo time e área do produto quando possível. Um 5 do time de mobile e um 5 do time de plataforma não precisam significar a mesma coisa.

Para uma escala de referência concreta, compare estes seis exemplos de story points, incluindo os limites de aceitação que tornam um item menor ou maior.

Passo 2: apresente um item do backlog

O responsável pelo backlog explica o resultado e os limites em alguns minutos. Evite detalhar uma implementação proposta como se estivesse decidida. Os desenvolvedores podem ver um caminho mais simples — ou uma dependência que altera toda a estimativa.

Uma abertura útil soa assim:

Um usuário autenticado pode exportar o relatório atual como CSV. Nesta rodada estão incluídos os filtros visíveis da tabela, mas não as exportações agendadas ou mapeamento customizado de colunas.

Então deixe o time fazer perguntas. Se uma pergunta alterar o escopo, atualize o item antes da votação.

Passo 3: vote em sigilo e revele junto

Cada estimador seleciona uma carta sem ver as escolhas dos outros. Votos ocultos reduzem a ancoragem no primeiro número, na pessoa mais experiente ou na expectativa do facilitador.

Revele somente após todos votarem. O Agilo pode revelar as cartas manualmente ou automaticamente depois que todos votarem, dependendo das configurações da sala. O facilitador também pode usar o temporizador da sala quando o time precisar de um limite suave para perguntas ou votação.

Não apresse quem escolhe ?. Essa carta é uma evidência útil: o item pode faltar contexto, estar fora da expertise de alguém ou conter uma suposição que vale a pena tornar visível.

Passo 4: discuta a variação, não cada número

Se os votos se agrupam em valores próximos, o time pode precisar só de uma breve confirmação. Se a variação for ampla — por exemplo, 3, 3, 5, 8, 13 — comece pelo raciocínio por trás das estimativas mais baixa e mais alta.

Faça perguntas como:

• O que o 13 inclui que o 3 não?
• Há uma dependência ou modo de falha que alguém não percebeu?
• Estamos estimando as mesmas condições de aceitação?
• Alguém está assumindo uma infraestrutura reutilizável que ainda não existe?
• Dividir o item eliminaria a principal incerteza?

O objetivo é entendimento compartilhado. O consenso pode vir depois, mas forçar todos a escolher a mesma carta sem resolver a diferença principal inviabiliza o exercício.

Quando uma pessoa vota 3 e outra vota 13: boas notícias — as cartas não estão quebradas. O time acabou de encontrar a conversa para a qual vieram. 😅

Interface atual do Agilo após a revelação: a variação de 3 a 8 estimula a comparação de pressupostos. A média 5,3 é um contexto, não uma resposta final automática.

Passo 5: esclareça, divida ou vote novamente

Após a discussão, escolha um dos três caminhos:

1. Revote. O item está claro e novas informações mudaram a visão do time.
2. Divida o item. A estimativa é alta porque vários resultados ou etapas técnicas foram agrupados.
3. Pause a estimativa. Uma decisão de produto, dependência ou investigação precisa ser resolvida primeiro.

O Agilo permite uma nova rodada de votação, mas não escolhe a estimativa final para a equipe. O facilitador e os estimadores ainda decidem qual valor reflete o entendimento compartilhado.

Passo 6: registre o resultado e siga em frente

Assim que a equipe concordar com a estimativa a ser usada, registre-a no item do backlog e selecione o próximo enquanto a sessão ainda estiver em ritmo. Se você usar a integração do Agilo com Jira, poderá importar issues do Jira com seu contexto e retornar a estimativa selecionada quando a sincronização estiver configurada.

Mantenha uma anotação separada para perguntas de acompanhamento. Não esconda escopo não resolvido atrás de um número apenas para concluir a lista.

Exemplo prático: cinco itens de backlog

Os valores abaixo pertencem a uma equipe fictícia de produto usando seus próprios itens de referência. São exemplos de raciocínio, não um gabarito universal.

Considere o item dos widgets. Os que votaram baixo imaginaram uma mudança apenas no layout para desktop. Os que votaram alto incluíram gestos móveis, ordenação persistente, acessibilidade por teclado e migração dos layouts existentes. Nenhuma média resolveria essa divergência. Dividir o item tornou o escopo explícito e gerou duas conversas mais significativas.

Erros comuns que enfraquecem a sessão

Tratar a média como a resposta

Uma média pode esconder duas interpretações incompatíveis. Discuta a variação primeiro. A estimativa final deve refletir o trabalho compreendido, não conveniência aritmética.

Permitir que a pessoa mais senior vote em voz alta

Uma vez que um número é falado, estimativas posteriores tendem a girar em torno dele. Mantenha as cartas ocultas até a revelação e peça o raciocínio após o voto independente.

Debater a implementação antes do resultado estar claro

Discussão técnica é valiosa, mas somente depois que todos entenderem o que o item precisa atingir. Caso contrário, a equipe pode estimar produtos diferentes.

Forçar uma estimativa para um item não pronto

"Precisamos de um número hoje" não remove uma dependência. Marque a questão, atribua um responsável e retorne quando a decisão ausente estiver disponível.

Comparar indivíduos ou equipes por pontos de história

Pontos são uma ferramenta local de planejamento. Transformá-los em meta de desempenho incentiva números inflados e torna as estimativas menos úteis.

Lista de verificação do facilitador

Antes da reunião:

• escolha de 5 a 8 itens de curto prazo;
• adicione contexto de aceitação e links;
• crie a sala e selecione o conjunto de cartas;
• confirme quem explicará os itens e quem votará;
• escolha um item de referência familiar.

Durante cada rodada:

• mantenha os votos ocultos até que todos estejam prontos;
• ouça os argumentos dos votos mais baixos e mais altos quando a variação for relevante;
• atualize o item quando as suposições mudarem;
• revote, divida ou pause em vez de forçar consenso;
• registre a estimativa selecionada e qualquer responsável por acompanhamento.

Após a reunião:

• garanta que as estimativas estejam visíveis no backlog;
• resolva itens pausados antes de chegarem ao planejamento da sprint;
• revise a escala somente quando a equipe a considerar consistentemente inútil.

Execute o fluxo de trabalho no Agilo

Agilo Planning Poker mantém o contexto do backlog, votação privada, revelação simultânea, rodadas repetidas e a estimativa selecionada em uma única sala. Você pode adicionar trabalho manualmente ou importar issues do Jira, usar um conjunto de cartas padrão ou personalizado e avançar diretamente para o próximo item após o consenso da equipe.

Crie uma sala de Planning Poker quando seus itens do backlog e participantes estiverem prontos.

Fontes e leitura adicional

• Agile Alliance: Planning Poker — o padrão básico de voto privado, revelação simultânea, discussão e rodadas adicionais.
• O Guia oficial do Scrum — a definição atual de Scrum e responsabilidades de dimensionamento do Product Backlog.