Em uma discussão recente na lista do Scrum Development, Tri Nguyen perguntou se os products owners devem participar da reunião de planning poker. Existe um consenso geral sobre isso? Ron Jeffries respondeu de forma direta:
Eles deveriam estar lá? Sim, para explicar o que está sendo votado.
Eles deveriam estimar? Não, não ao menos que ele planeje codificar aquilo.
É isso, durante o planning poker, o product owner deve ser responsável por explicar todas as dúvidas que o time tiver sobre cada história - e.g., qual funcionalidade deve ser incluída, qual funcionalidade deve ser excluída. qual regras devem ser seguidas, e assim por diante. Mas o product owner não deve ajudar na estimativa de quanto esforço será necessário para a completar a história. A estimativa de esforço quantitativa - na forma de planning poker - deve ser de total responsabilidade do time de desenvolvimento.
A razão para excluir o product owner de prover estimativas durante a sessão de planning poker é simples. O time de desenvolvimento precisa fazer um comprometimento sobre quantas funcionalidades eles irão completar durante o sprint. Se o product owner tem o poder de exercer alguma influência sobre esse comprometimento, então o time não pode chamar esse comprometimento de verdadeiro e próprio, eles irão perder a auto organização e o senso de compromentimento que eles tinham, perdendo assim o poder do Scrum.
Existe uma situação especial, entretanto, onde o product owner pode prover alguma influência sobre a votação na sessão de planning poker. Dan Rawsthorne colocou:
Lembrem que o [product owner] é um papel, e uma pessoa. Essa pessoa pode exercer outros papéis e estes podem ser parte da estimativa de esforço.
Quando um product owner também é um desenvolvedor, o product owner pode, de fato, exercer influência sobre a sessão de planning poker. Deve ser considerado quanto tempo o papel de product owner custa. Entretanto, é relativamente raro encontrar um product owner que iria ser desenvolvedor também.
O product owner deveria ficar totalmente mudo sobre os esforços escolhidos durante o planning poker pelo time de desenvolvimento? Não em todos os casos. O Planning poker é uma ferramenta valiosa para detectar mal-entendidos entre o product owner e o time de desenvolvimento, e esses mal-entendimentos, ao serem detectados, devem ser corrigidos o mais rápido possível. Henrik Kniberg, em seu livro Scrum and XP from the Trenches, da um exemplo:
O time e o product owner estão felizes com o que foi planejado para o sprint e estão prontos para encerrar a reunião. O Scrum master então diz "espera um segundo, a história com o nome 'add user' não foi votada. Vamos estimar!" Após algumas rodadas de planning poker o time chega ao consenso de 20 story points, então o product owner levanta e grita "o queeeeeee?!". Depois de alguns minutos de discussão, eles verificaram que o time entendeu mal o escopo da história, eles pensaram que a história significava 'criar uma ótima interface web, adicionar, deletar e remover usuários', quando na realidade o product owner queria apenas 'adicionar usuários realizando SQL manuais diretamento no Banco de Dados'. Eles estimaram novamente e chegaram em 5 story points.
Nesse caso, o planning poker serviu como uma ferramenta de verificação entre as duas partes, prevenindo um mal-entendimento sobre o escopo atual da história.