O momento certo para o Planning Poker

Planning Poker é um método de estimativa baseado em consenso. Por isso, recomendo usá-lo também para itens que exigem consenso – ou seja, mais para Product Backlog Items do que para Tasks em um Sprint Backlog. Neste artigo, vou abordar novamente o Planning Poker e explicar quando ele deve ser utilizado.

Razões para estimar User Stories

Estimar User Stories em um Product Backlog tem duas razões:

1.) O Product Backlog pode ser priorizado. Imagine dois itens do Product Backlog que o Product Owner considera equivalentes. O item com os custos mais baixos será trabalhado primeiro. As avaliações dos itens dependem, portanto, dos seus custos e podem ser usadas para a priorização.

2.) A empresa pode fazer previsões de longo prazo. O escopo do trabalho precisa ser conhecido para que o Product Owner possa dizer quando e quanto pode ser entregue.

Quando se deve jogar Planning Poker?

Com a ajuda dos pontos mencionados acima, é possível descobrir quando uma equipe deve fazer estimativas. Por um lado, isso deve acontecer cedo o suficiente para que ambos os pré-requisitos possam ser cumpridos. Por outro lado, não deve acontecer antes do absolutamente necessário.

Na prática, existem duas situações em que uma equipe deve jogar Planning Poker.

Um bom momento para o Planning Poker é, por exemplo, após um Story Writing Workshop, no qual muitos Product Backlog Items foram criados. Esses workshops devem ser realizados aproximadamente a cada trimestre.

Assim, o Product Owner e a equipe podem definir um objetivo maior (que não pode ser alcançado em um único Sprint) e criar as User Stories necessárias para isso.

Normalmente, em um Story Writing Workshop trimestral surgem de 20 a 50 Product Backlog Items. Se conseguires estimar cerca de 20 itens por hora, precisarás de aproximadamente duas horas por trimestre para fazer todas as estimativas.

Além disso, o Planning Poker também pode ser realizado uma vez por Sprint. Algumas equipes fazem isso durante a reunião regular de Product Backlog Grooming. E isso é perfeitamente aceitável – desde que todos os membros da equipe participem.

Se nem todos os membros da equipe estiverem envolvidos, o Planning Poker também pode ser realizado após um Daily Standup perto do final de um Sprint. Se uma equipe fizer estimativas cedo demais durante um Sprint, pode ser necessário repetir tudo para Stories que forem adicionadas posteriormente.

No entanto, a estimativa também não deve ser feita tarde demais. Caso contrário, o Product Owner não conseguirá considerar esses itens ao definir os itens para o próximo Sprint.

Quando não se deve jogar Planning Poker?

Existe um momento que é desfavorável para o Planning Poker: no início de uma reunião de Sprint Planning. Nesse caso, já é tarde demais para o Product Owner orientar a priorização com base nas novas estimativas.

Pode haver Product Owners que conseguem reorganizar as prioridades em pouquíssimo tempo. No entanto, ter mais tempo é sempre melhor.

Outro problema é que uma equipe quase sempre gasta tempo demais com estimativas quando um Sprint Planning começa com Planning Poker. Acredito que isso acontece porque os membros da equipe já começam a pensar diretamente nos detalhes das suas User Stories.

No Planning Poker, porém, eles deveriam fazer uma estimativa menos detalhada das suas User Stories. É difícil dar uma estimativa tão aproximada em uma reunião quando, na verdade, as Tasks deveriam ser avaliadas com muito mais precisão.

Isso leva a discussões desnecessariamente longas. E isso, por sua vez, faz com que a equipe demore muito mais do que se fizesse as duas coisas separadamente.

Com essas diretrizes, você deve conseguir encontrar o momento certo para o Planning Poker.

Este texto foi retirado do blog de Mike Cohn e foi traduzido por nós para o alemão.