Se você já participou de uma Sprint Planning, sabe que estimar tarefas pode ser um dos momentos mais tensos da cerimônia. Cada pessoa tem uma percepção diferente de complexidade, e sem um método estruturado, a discussão vira debate infinito. É exatamente aí que entra o Planning Poker — uma técnica simples, colaborativa e surpreendentemente eficaz para alinhar o time.
O que é Planning Poker?
Planning Poker (também chamado de Scrum Poker) é uma técnica de estimativa ágil baseada em consenso. Em vez de uma pessoa definir o esforço de cada tarefa, todo o time vota simultaneamente usando cartas com valores numéricos. Os votos são revelados ao mesmo tempo, eliminando o viés de ancoragem — aquela tendência de concordar com quem fala primeiro.
A técnica foi popularizada por James Grenning em 2002 e amplamente difundida por Mike Cohn no livro Agile Estimating and Planning. Hoje, é o método de estimativa mais utilizado por equipes Scrum no mundo.
Por que funciona?
- Elimina ancoragem cognitiva: como os votos são simultâneos, ninguém influencia a opinião dos outros
- Promove discussão produtiva: divergências viram oportunidade para alinhar entendimento
- Envolve todo o time: desenvolvedores, QAs e designers participam igualmente
- É rápido: a maioria das tarefas converge em 1-2 rodadas
A sequência de Fibonacci nas estimativas
O Planning Poker utiliza a sequência de Fibonacci modificada como escala de pontuação:
1, 2, 3, 5, 8, 13, 21, 34, ☕Mas por que Fibonacci e não uma escala linear (1, 2, 3, 4, 5…)?
A resposta está na incerteza. Quanto mais complexa uma tarefa, mais difícil é estimar com precisão. A sequência de Fibonacci reflete isso naturalmente: a diferença entre 1 e 2 é pequena (tarefas simples são fáceis de comparar), mas a diferença entre 13 e 21 é grande — porque nesse nível de complexidade, a margem de erro também é grande.
| Valor | Significado típico |
|---|---|
| 1 | Tarefa trivial — mudar uma label, ajustar uma cor |
| 2 | Tarefa simples com padrão claro |
| 3 | Tarefa pequena que exige alguma atenção |
| 5 | Tarefa média com lógica moderada |
| 8 | Tarefa complexa, múltiplos componentes envolvidos |
| 13 | Tarefa grande — considere quebrar em partes menores |
| 21 | Épico disfarçado — definitivamente precisa ser quebrado |
| 34 | Impossível estimar — falta clareza, precisa de refinamento |
| ☕ | “Preciso de café” — tarefa incompreensível ou fora do escopo |
Dica: Se o time está votando consistentemente 13 ou mais, o Product Owner deve refinar melhor as histórias antes da Planning.
Como funciona uma sessão de Planning Poker
Uma sessão típica segue este fluxo:
1. O Product Owner apresenta a história
O PO descreve a user story, critérios de aceitação e responde dúvidas do time. É fundamental que todos entendam o que precisa ser feito antes de estimar quanto esforço leva.
Como [usuário],
eu quero [funcionalidade],
para que [benefício].
Critérios de aceitação:
- [ ] Critério 1
- [ ] Critério 2
- [ ] Critério 32. Cada membro seleciona uma carta
Sem discussão prévia, cada pessoa escolhe a carta que representa sua estimativa. O voto é secreto até a revelação — isso é crucial para evitar ancoragem.
3. Revelação simultânea
Todas as cartas são viradas ao mesmo tempo. Se há consenso (todos votaram o mesmo valor ou valores próximos), a estimativa é aceita.
4. Discussão de divergências
Se houver divergência significativa — por exemplo, alguém votou 3 e outra pessoa votou 13 — o time discute:
- Quem votou mais alto explica quais riscos ou complexidades está enxergando
- Quem votou mais baixo explica por que considera mais simples
- Frequentemente, a divergência revela que alguém sabe de algo que os outros não sabem: uma dependência escondida, um débito técnico, uma regra de negócio não documentada
5. Nova rodada (se necessário)
Após a discussão, o time vota novamente. Na maioria dos casos, a segunda rodada já converge. Se após 2-3 rodadas não há consenso, o Scrum Master pode:
- Adotar o valor mais alto (abordagem conservadora)
- Usar a média arredondada para o Fibonacci mais próximo
- Marcar a história para refinamento posterior (precisa de mais análise)
Boas práticas para Planning Poker eficaz
Estime complexidade, não tempo
Story points representam complexidade relativa, não horas. Uma tarefa de 5 pontos não significa 5 horas — significa que é ~2.5x mais complexa que uma tarefa de 2 pontos. Isso libera o time da armadilha de converter pontos em horas e depois virar cobrança.
Defina uma tarefa de referência
Escolha uma tarefa que o time já completou e que todos concordam ser um 3 (ou 5). Use essa tarefa como âncora para comparar novas estimativas:
“Essa história é mais complexa ou menos complexa que a implementação do filtro de busca que fizemos na sprint passada?”
Limite o tempo por história
Defina um timebox de 3-5 minutos por história. Se após esse tempo não há consenso, a história precisa de refinamento — levar adiante vai gerar uma estimativa inútil.
Inclua todo o time
Desenvolvedores, QAs, designers, DevOps — qualquer pessoa que vai trabalhar na entrega deve votar. O QA pode enxergar complexidade de teste que o dev não vê. O DevOps pode saber de uma limitação de infra.
Não force consenso artificial
Se uma pessoa votou diferente, ouça antes de pedir que mude o voto. A divergência é o momento mais valioso do Planning Poker — é quando o time descobre riscos que ninguém tinha pensado.
Planning Poker remoto: como fazer com times distribuídos
Com equipes remotas e híbridas, cartas físicas não funcionam. A solução é usar uma ferramenta online de Planning Poker que simula a experiência:
- O facilitador cria uma sala e compartilha o link
- Participantes entram sem precisar de cadastro
- Cada pessoa seleciona seu voto na interface
- O facilitador revela os votos quando todos votaram
- O time discute divergências via call (Google Meet, Teams, Zoom)
- Nova rodada se necessário
Criamos uma ferramenta gratuita para isso
Na DevPlus, desenvolvemos um Planning Poker online e gratuito que você pode usar com seu time agora mesmo:
- 100% gratuito — sem limites de salas, participantes ou rodadas
- Sem cadastro — basta digitar seu nome e criar uma sala
- Sequência Fibonacci — 1, 2, 3, 5, 8, 13, 21, 34 e ☕
- Link de tarefa — cole o link do Jira, Trello ou Azure DevOps para contexto rápido
- Gerenciamento de sala — o facilitador controla revelação, novas rodadas e pode remover participantes
- Funciona em qualquer dispositivo — desktop, tablet ou celular
→ Experimente agora — é grátis e instantâneo
Planning Poker na Sprint Planning: passo a passo
Aqui está como integrar o Planning Poker na sua cerimônia de Sprint Planning:
Antes da Planning (preparação)
- Product Owner ordena o backlog com as histórias prioritárias
- Refinamento prévio das top 10-15 histórias (critérios de aceitação escritos)
- Scrum Master prepara a ferramenta de Planning Poker com a sala criada
Durante a Planning
- PO apresenta a primeira história (2-3 min)
- Time tira dúvidas (2-3 min)
- Votação com Planning Poker (1 min)
- Discussão de divergências (2-3 min)
- Segunda votação se necessário (1 min)
- Registro do resultado e próxima história
Tempo estimado
| Tamanho do Sprint | Histórias estimadas | Duração sugerida |
|---|---|---|
| 1 semana | 5-8 histórias | 1 hora |
| 2 semanas | 8-15 histórias | 2 horas |
| 3 semanas | 12-20 histórias | 3 horas |
Regra de ouro: se a Planning está levando mais de 4 horas, o backlog não foi refinado adequadamente.
Erros comuns no Planning Poker
❌ Converter pontos em horas
“Se 1 ponto = 4 horas, então 8 pontos = 32 horas = 4 dias.”
Esse raciocínio destrói o propósito dos story points. A velocidade do time é medida em pontos por sprint, não em horas. Pontos são relativos, horas são absolutas — misturar os dois gera estimativas piores que nenhuma estimativa.
❌ Copiar o voto do tech lead
Se o sênior vota primeiro e fala “acho que é 5”, todo mundo vai votar 5. Por isso a revelação simultânea é obrigatória. Se alguém falar o voto antes da revelação, a rodada deve ser invalidada.
❌ Gastar 20 minutos discutindo uma história
Se após 2 rodadas não há consenso, pare. A história precisa de refinamento, não de mais discussão. Marque para revisão e siga para a próxima.
❌ Estimar bugs como 0 pontos
Bugs consomem esforço como qualquer outra tarefa. Se o time não pontua bugs, a velocidade calculada será inflada e o planejamento da sprint seguinte será impossível.
Conclusão
Planning Poker é simples de aprender, rápido de executar e extremamente eficaz para criar alinhamento no time. A chave está nos três pilares: voto simultâneo (elimina ancoragem), discussão de divergências (revela riscos) e sequência Fibonacci (reflete a incerteza natural de estimativas).
Se seu time ainda estima “no olhômetro” ou depende de uma pessoa para definir o esforço, experimente o Planning Poker na próxima Sprint Planning. Em poucas sprints, a qualidade das estimativas e a previsibilidade da equipe vão melhorar significativamente.
Comece agora — nosso Planning Poker é gratuito e não precisa de cadastro →