MÉTODOS, PROJETOS

Planning poker: A técnica baseada no consenso

Planning poker: A técnica baseada no consenso
Planning poker: A técnica baseada no consenso

Planning poker ou em português “Poker do planejamento”, é uma técnica baseada no consenso para estimar, é um jogo e ao mesmo tempo um exercício.

Através dessa técnica podemos estimar o esforço necessário para determinada quantidade de trabalho, tendo como base informações recolhidas do cliente, normalmente sendo, através de estórias de usuário.

O planning poker foi definido e nomeado pela primeira vez por James Grenning, em 2002, e mais tarde popularizado por Mike Cohn, no livro Agile Estimating and Planning.

De maneira resumida, no planning poker cada membro da equipe recebe um conjunto de cartas, com os valores de uma determinada sequência.

Em seguida, a cada estória de usuário analisada, cada membro da equipe joga uma carta com a face para baixo sobre a mesa, nela estará contido o valor numérico de pontos que o mesmo considera justo para que a estória seja concluída.

Caso haja grandes diferenças entre as cartas jogadas, os membros que jogaram as cartas de maior e menor valor explicarão suas razões e, então, com base em suas explicações, as cartas são jogadas novamente até que um consenso seja encontrado e uma estimativa seja definida.

 A sequência de Fibonacci

Como citei anteriormente, as cartas possuem uma sequência de valores, que podem ser uma sequência simplificada (0, 1, 2, 3, 5, 8, 13, 20, 40, 100) ou uma sequência de Fibonacci. De acordo com a Wikipédia, a sucessão de Fibonacci ou sequência de Fibonacci é uma sequência de números naturais, onde os dois primeiros números começam normalmente por 0 e 1, na qual, cada termo subsequente corresponde a soma dos dois anteriores. Abaixo temos uma imagem que ilustra a lógica da sequência Fibonacci.

A principal razão que nos leva a acreditar que a seqüência de Fibonacci é a melhor opção, é refletir na inerente incerteza que podemos ter em estimativas de itens maiores. Na imagem abaixo, podemos enxergar um conjunto de cartas que seguem a sequência Fibonacci. Você poderá encontrar várias versões diferentes de baralho para o planning poker através da internet, logicamente, você está livre para criar a sua própria versão e aplicá-la junto a sua equipe. Porém, como sugestão, entrego um exemplo que você poderá seguir.

Entendendo o baralho

Você deve ter percebido que existe alguns elementos, vamos dizer, “confusos”, são eles: ?, 0, 0.5, […] e uma xícara de café. Mas, o que eles significam e por que estão presentes no planning poker? Vou te explicar.

  • ? (interrogação): Significa que o membro não se sente confiante para atribuir um valor a tarefa;
  • 0 (zero): Significa que a tarefa é absolutamente desnecessária e deveria ser descartada;
  • 0.5 (meio): Significa que a tarefa necessita de uma pequeno esforço para ser concluída;
  • … (infinito): Significa que a tarefa é extremamente importante;
  • Xícara de café: Significa uma pausa para refletir antes de tomar a decisão. Esta pausa é importante e deve ser respeitada quando solicitada, é muito provável que os membros não abusem dela.

Os outros números são a representação arbitrária do sentimento dos membros, quanto ao esforço necessário, para a realização da tarefa. Perceba que o planning poker é bastante simples e divertido, não há como um integrante se confundir ou não entender o jogo.

Planning poker em ação

Beleza, você agora já entende como é feita a sequência das cartas, conhece o significado dos elementos confusos e agora está em sua reunião de planejamento de sprint, com toda sua equipe (4 pessoas), com o ScrumMaster e com o Product Owner. Conseguiu imaginar? Show! O planning poker pode ser utilizado em dois momentos: na priorização de tarefas e na estimativa de esforço para concluí-las. Eu vou mostrar o cenário para uma estimativa de esforço, pois tanto para estimativa, quanto para priorização o jogo é o mesmo.

Suponha que vocês já tenham jogado um planning poker para a priorização de tarefas, sendo assim, já definiram quais tarefas deverão ser executadas primeiro e agora irão estimar o esforço para desenvolvimento delas. Todos (menos o ScrumMaster e o P.O.) receberão seus respectivos baralhos, cada um com os números 0, 0.5, 1, 2, 3, 5, 8, 13, 21 e os símbolos de interrogação, infinito e xícara de café. O ScrumMaster pede então que o Product Owner leia a primeira estória de usuário, podemos dizer que seria a seguinte: “Como usuário, quero acessar o site através do celular e usar todos os recursos, assim como no navegador do desktop”. O ScrumMaster pede que todos os participantes pensem um pouco sobre o esforço para desenvolver aquela estória e, em seguida, que todos mostrem suas cartas. O resultado da jogada é o seguinte:

1° Rodada
Membro Carta do poker
Lucas8
Ana5
Alan21
Carlos3
Maria 5

Fica claro que Alan e Carlos fazem jogadas extremas. Nesta situação o ScrumMaster pergunta a ambos o motivo de suas escolhas, eles respondem:

Alan diz:

Teríamos que fazer um outro site para o ambiente mobile, um novo HTML, CSS, JS e integrar uma nova rotina à existente hoje. É necessário um grande esforço no design e na programação para que o site se torne mobile. Temos que considerar os plugins utilizados hoje e encontrar similares no mercado para customização.

Carlos diz:

Na verdade, poderíamos utilizar a estrutura já existente hoje e apenas ajustar o CSS e alguns elementos HTML, assim manteríamos tudo junto e o esforço para manutenção seria menor. Devemos levar em consideração que o usuário deseja ter os mesmos recursos, ou seja, seria uma replica. O site possui muitas páginas dinâmicas e isso faz com que o ajuste em uma, replique em várias.

Acontece então uma breve discussão e uma nova rodada é realizada. O resultado é o seguinte:

2° Rodada
Membro Carta do poker
Lucas8
Ana5
Alan8
Carlos5
Maria 5

Perceba que os valores estão mais uniformes, com esse cenário você pode assumir algumas opções, são elas:

  1. Continuar a incentivar a discussão até que um consenso geral entre os membros seja obtido;
  2. Fazer uma média dos valores, levando em consideração a proximidade entre eles;
  3. Como os valores estão próximos, assumir o maior valor.

Em nosso caso optamos por escolher o maior valor, sendo assim, o número de pontos para essa tarefa (Story Points) seria de 8. Esse ciclo de jogadas é repetido em cada tarefa do sprint backlog (pode ocorrer também no product backlog) até que todas sejam concluídas. Com o tempo você facilmente saberá definir quantos Story Points conseguirá assumir em cada sprint, ajustando suas estimativas quanto ao desenrolar do projeto.

Gostou? Então deixe seu comentário e compartilhe com seus amigos. 🙂
Um grande abraço e até a próxima!

Você pode gostar também