Planning Poker é uma técnica de estimativa ágil baseada em consenso, usada principalmente em metodologias Scrum. Os membros da equipe usam cartas numeradas (geralmente seguindo a sequência de Fibonacci) para estimar a complexidade, esforço ou tempo necessário para completar uma tarefa ou história de usuário.

O Planning Poker funciona em rodadas: 1) O Product Owner apresenta uma história de usuário; 2) A equipe discute e esclarece dúvidas; 3) Cada membro escolhe uma carta secretamente; 4) Todos revelam as cartas simultaneamente; 5) Se há consenso, a estimativa é aceita; 6) Se não, discute-se as diferenças e repete-se o processo.

A sequência de Fibonacci (1, 2, 3, 5, 8, 13, 21...) é usada porque reflete a incerteza natural das estimativas. Conforme as tarefas ficam maiores, torna-se mais difícil estimar com precisão, e os intervalos maiores da sequência capturam essa incerteza crescente.

Os benefícios incluem: estimativas mais precisas através do consenso da equipe, maior engajamento de todos os membros, redução da influência de opiniões dominantes, melhor compreensão dos requisitos, identificação precoce de riscos e dependências, e fortalecimento da colaboração da equipe.

Story Points representam a complexidade relativa, esforço e incerteza de uma tarefa, sendo mais estáveis ao longo do tempo. Estimativas em horas são absolutas e podem variar muito entre pessoas e contextos. Story Points focam no "quão difícil" enquanto horas focam no "quanto tempo".

O ideal são 3-9 pessoas, incluindo desenvolvedores, testadores, arquitetos e o Scrum Master. Muito poucas pessoas limitam perspectivas diferentes, enquanto muitas pessoas tornam o processo longo e difícil de gerenciar. O Product Owner participa apresentando as histórias, mas geralmente não vota.

Uma sessão típica dura 1-4 horas, dependendo do número de histórias e da complexidade. Recomenda-se fazer pausas a cada hora e limitar a 2-3 horas por sessão para manter a concentração. Para sprints de 2 semanas, geralmente 2-4 horas são suficientes.

Os valores mais comuns são: 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, ∞ (infinito) e ? (dúvida). Algumas equipes usam apenas Fibonacci modificado: 1, 2, 3, 5, 8, 13, 21. O importante é ter uma progressão que reflita a incerteza crescente.

Use ferramentas como Battle Poker, Planning Poker Online, ou similares. Garanta que todos tenham boa conexão de internet, câmeras ligadas para melhor comunicação, e estabeleça regras claras. Ferramentas digitais podem até facilitar o processo com timers automáticos e histórico de estimativas.

Quando as estimativas são muito diferentes: 1) Peça para os membros com estimativas extremas explicarem seu raciocínio; 2) Discuta aspectos técnicos, dependências ou riscos não considerados; 3) Faça uma nova rodada de estimativas; 4) Se persistir a diferença, considere quebrar a história em partes menores.

Histórias estimadas acima de 13 pontos devem ser quebradas em histórias menores. Use técnicas como User Story Mapping, decomposição funcional, ou separação por personas. Histórias grandes geralmente indicam falta de clareza nos requisitos ou dependências complexas.

O Product Owner apresenta e explica as histórias de usuário, esclarece dúvidas sobre requisitos, define critérios de aceitação, e prioriza as histórias. Geralmente não participa das estimativas para não influenciar a equipe técnica, mas pode opinar sobre valor de negócio.

O Scrum Master facilita o processo mantendo o foco, gerenciando o tempo, garantindo que todos participem, mediando discussões, e ajudando a resolver conflitos. Deve permanecer neutro nas estimativas e focar na qualidade do processo de consenso.

Critérios de aceitação claros e bem definidos são essenciais para estimativas precisas. Eles ajudam a equipe a entender exatamente o que precisa ser feito, reduzem ambiguidades, e permitem estimativas mais confiáveis. Histórias sem critérios claros tendem a ter estimativas muito divergentes.

Durante as discussões, questione: "Esta história depende de outras tarefas?", "Precisamos de APIs externas?", "Há dependências de outras equipes?". Mapeie dependências visualmente e considere seu impacto nas estimativas. Dependências podem aumentar significativamente a complexidade.

A velocidade é a soma dos story points das histórias completadas em um sprint. Após 3-5 sprints, você terá uma média confiável. Use esta média para planejar sprints futuros, considerando variações sazonais, férias, e mudanças na equipe.

Novos membros devem observar algumas sessões antes de participar ativamente. Explique o processo, as regras, e o significado dos story points. Emparelhe-os com membros experientes durante as primeiras estimativas. Suas perspectivas frescas podem ser valiosas.

Não são iguais, mas complementares. O Refinamento de Backlog é um processo contínuo de preparação das histórias (esclarecimentos, divisão, priorização). O Planning Poker é uma técnica específica de estimativa que pode ser usada durante o refinamento ou na Sprint Planning.

O Planning Poker em grupo é mais eficaz que estimativas individuais porque: combina diferentes perspectivas, reduz viés individual, promove discussões valiosas, identifica riscos e dependências, e cria maior comprometimento da equipe com as estimativas.

Questões técnicas devem ser discutidas abertamente: complexidade do código, necessidade de refatoração, impacto na arquitetura, débito técnico, e requisitos não-funcionais. Desenvolvedores seniores devem compartilhar conhecimento técnico para estimativas mais precisas.

Na retrospectiva, analise: quais estimativas foram precisas/imprecisas e por quê, que fatores não foram considerados, como melhorar a decomposição de histórias, e ajustes no processo de Planning Poker. Use dados históricos para calibrar futuras estimativas.

Ferramentas populares incluem: Battle Poker, Planning Poker Online, Scrum Poker Cards, PlanITpoker, e Pointing Poker. Escolha baseado em: facilidade de uso, integração com outras ferramentas, suporte a equipes remotas, histórico de estimativas, e custo.

Métricas importantes: precisão das estimativas vs. realidade, redução na variância das estimativas ao longo do tempo, aumento na velocidade da equipe, melhoria na previsibilidade de entregas, e satisfação da equipe com o processo de estimativa.

O Planning Poker promove transparência, colaboração, e responsabilidade compartilhada. Reduz a cultura de culpa por estimativas incorretas, encoraja discussões abertas sobre dificuldades, e democratiza o processo de tomada de decisões técnicas.

Para projetos grandes, use Planning Poker por equipe separadamente, depois normalize estimativas entre equipes. Considere usar técnicas como T-shirt sizing para épicos maiores, e mantenha comunicação constante entre equipes para alinhamento.