Planning poker: a estratégia completa para estimativas ágeis

Imagine que você comprou uma casa e planeja reformar a cozinha. Você pede a um empreiteiro uma estimativa de quanto tempo levará a reforma e quanto custará aproximadamente. Ele lhe dá uma estimativa, mas dois meses depois você se arrepende da sua decisão porque o projeto está muito além do cronograma original e bem acima do orçamento. 

Quando você tem a opinião de apenas uma pessoa, só tem a contribuição e a experiência dela para considerar. No entanto, quando você envolve mais pessoas com diferentes experiências, obtém uma estimativa mais completa e precisa do trabalho que precisa ser feito.

Essa estimativa baseada em consenso é a base do método ágil de planning poker. 

O que é o pôquer de planejamento?

O planning poker é um método de estimativa que ajuda a equipe ágil a projetar a quantidade de esforço que uma história de usuário em um backlog do produto pode levar para ser concluída. Frequentemente usado em metodologias ágeis de gestão de projetos, às vezes é chamado de “pôquer Scrum” ou “pôquer de apontamento”. A palavra “pôquer” no nome se refere às cartas que cada membro da equipe usa durante o processo.

História do planning poker

O planning poker é baseado em uma técnica conhecida como Wideband Delphi. Wideband Delphi é um processo de estimativa baseado em consenso desenvolvido em meados do século XX pela RAND Corporation, um think tank sem fins lucrativos. 

James Grenning, autor de “The Manifesto for Agile Software Development” (O Manifesto para o Desenvolvimento Ágil de Software), refinou a técnica Wideband Delphi em 2002 e a renomeou como Planning Poker. Foi então refinada ainda mais e popularizada por Mike Cohn no seu livro de 2005, “Agile Estimating and Planning” (Estimativa e planejamento ágil, em tradução livre). 

Como funciona o pôquer de planejamento

O processo de planning poker ocorre no início do processo de planejamento do sprint, para que os mestres do Scrum e os gerentes de produto possam ter uma noção precisa de quanto trabalho pode ser concluído em cada sprint. Funciona assim:

1. Crie cartas de pôquer de planejamento

Todos na sua equipe Scrum ou Agile têm um baralho de cartas com valores diferentes. Cada carta terá um destes valores: 0, 1, 2, 3, 5, 8, 13, 20, 40 e 100. Esses números podem parecer aleatórios, mas são, na verdade, variações arredondadas da sequência de Fibonacci. Esses valores geralmente representam Story points. No entanto, algumas equipes podem usá-los como uma estimativa baseada no tempo para determinar quanto tempo uma história de usuário pode levar para ser concluída. A estimativa baseada no tempo mais comum é medida em horas.

O proprietário do produto ou o mestre do Scrum atuará como moderador e lerá uma história de usuário específica do produto ou do backlog de sprint. Os membros da equipe têm a oportunidade de fazer perguntas e esclarecer o que for necessário para que todos possam ter uma noção precisa do trabalho que precisa ser concluído para esse item específico do backlog. 

Aqui estão algumas perguntas que a sua equipe pode fazer para entender melhor uma história de usuário:

• Quais são algumas técnicas diferentes que podemos usar para completar essa história?

• Quantas pessoas precisarão trabalhar nesta história?

• Como as partes interessadas reagirão se houver atrasos nesta história?

2. Vote em cada história de usuário

Depois que a equipe terminar a discussão de uma história de usuário, cada estimador escolhe uma carta que corresponda à quantidade de esforço ou story points que ele acredita estar relacionada a esse item do backlog. Todos revelam a sua carta ao mesmo tempo. Se todos escolherem a mesma estimativa, ela se torna a estimativa oficial para esse item do backlog. A meta é que todos tenham a mesma estimativa. 

3. Chegue a um consenso

Se os membros da equipe tiverem opiniões divergentes sobre as estimativas iniciais, o membro da equipe com a estimativa mais alta e o membro da equipe com a estimativa mais baixa devem dedicar algum tempo para discutir por que escolheram esse número específico. Depois que essa discussão for concluída, todos selecionam novamente os seus cartões. Esse processo se repete até que a equipe chegue a um consenso. 

4. Planeje o sprint

Agora que todos os itens do seu backlog têm estimativas, é muito mais fácil planejar um sprint com precisão. Como toda a equipe chegou a um consenso sobre a duração de cada tarefa, é muito mais provável que você consiga ajustar a quantidade certa de trabalho aos seus sprints.

Quando realizar uma sessão de pôquer de planejamento

O planning poker normalmente ocorre logo antes do processo de planejamento do sprint, para que o gestor de produto ou o mestre do Scrum possa ter uma noção precisa do trabalho antes de programar um sprint. Você pode usar este método de estimativa uma vez por sprint. Como os itens são continuamente adicionados a um backlog de produto ou de sprint, você deve ter um suprimento constante de itens de backlog para puxar em cada sprint. 

Se você tiver apenas uma pequena quantidade de histórias de usuário para discutir no seu backlog do produto, pode combinar esta sessão com o final de uma reunião diária em pé, já que todos os membros da equipe já estarão presentes. 

Os benefícios do pôquer de planejamento

O principal benefício do pôquer de planejamento é que as estimativas da equipe são mais precisas. Ter uma estimativa precisa é uma parte importante do processo de planejamento do sprint, porque dá à sua equipe e às partes interessadas um cronograma realista de quando uma tarefa será concluída.

Aqui estão mais algumas maneiras pelas quais o planning poker pode beneficiar a sua equipe ágil:

• Cada membro da equipe tem voz. Todos na equipe de desenvolvimento são importantes, e este processo lhes dá a oportunidade de fazer com que a sua contribuição seja conhecida. Isso pode ajudar os membros da equipe a se manterem mais envolvidos com o trabalho. 

• Os membros da equipe têm a oportunidade de conversar sobre as histórias de usuário. Durante o processo de pôquer de planejamento, a equipe de desenvolvimento tem a oportunidade de trabalhar em conjunto para discutir as histórias de usuário antes que qualquer trabalho realmente comece. Isso ajuda as pessoas a se alinharem sobre como resolver certas histórias de usuário, independentemente do desenvolvedor atribuído a essa história. 

• As estimativas de tarefas são relativas a outras tarefas. Quando a equipe usa story points para representar o número na carta de planning poker, fica mais fácil entender a quantidade de esforço que uma tarefa específica exigirá com base em outras tarefas no funil. Por exemplo, uma história de usuário com uma estimativa de 2 no planning poker será muito mais fácil de concluir do que uma história de usuário com uma estimativa de 40.

Planeje o seu sprint com ferramentas de gestão do trabalho

Mantenha a sua equipe Agile em sintonia usando ferramentas de gestão do trabalho. A Asana ajuda a planejar e organizar os seus projetos ágeis por meio de uma ferramenta flexível e colaborativa. Quer a sua equipe trabalhe em um quadro Kanban ou em um cronograma mais linear, a Asana tem os recursos para ajudar a sua equipe Agile a criar rapidamente.