O que é Planning poker

O Planning Poker é uma técnica para determinar o esforço que levará para o desenvolvimento de uma determinada funcionalidade de um produto ou projeto. É importante entender que no Planning Poker não é necessário detalhar o tempo em horas para cada tarefa.

Está técnica permite a interação de todos membros do time a fim de que seja possível identificar qual tarefa demanda mais esforço.

O Planning Poker é como um jogo de cartas onde cada carta tem um respectivo valor e funcionalidade.

A saber, existem diversos estudos de mercado que sinalizam que 1 Story Point representa 6 horas de trabalho, embora outros indiquem que uma Story Point corresponde a 4 horas, mas, essa não é uma prática recomendada, afinal a principal característica do Story Point é servir como base para estimar se uma User Story é maior ou menor que outra.

Quem deve participar

É necessário que o Product Owner esteja presente durante o “jogo” para que o mesmo possa tirar dúvidas, apresentar e priorizar os itens que venham a existir, além disso, o Scrum Master deve participar sendo uma espécie de facilitador do jogo, além desses dois perfis o time de desenvolvimento deverá estar presente para jogar.

É importante que todo o time de desenvolvimento tenha um baralho, afinal, cada um irá escolher uma carta individualmente.

Como funciona o Planning Poker

Primeiramente para iniciar o Planning Poker cada pessoa deve ter um baralho com algumas cartas, sendo as mais comuns 0, ½, 1, 2, 3, 5, 8, 13,20,100, “café” e “?”, logicamente existem outros tipos de baralhos com mais ou menos cartas. Já vou detalhar mais adiante o que significa cada uma delas mas por enquanto vamos entender como funciona.

Explicação dos cards

De início o Product Owner deve ler os cards(User Stories) e apresentar para a equipe, não precisa ser necessariamente o PO que deve ler os cards.

Cada card deve conter uma User Story para desenvolvimento.

O PO é a figura responsável por explicar o que deve ser desenvolvido, por tirar as dúvidas e evitar o retrabalho do time de desenvolvimento.

Possíveis dúvidas

Eventualmente podem surgir dúvidas sobre determinada User Story.

Após o PO explicar os cards fica a critério do time de desenvolvimento solicitar mais informações ou prosseguir para a escolha das cartas.

Com isso serão realizadas rodadas de forma a estimar o esforço para cada card, durante as rodadas o time de desenvolvimento deve estimar os cards considerando a complexidade em desenvolver e testar as funcionalidades, com exceção do PO.

Estimativas diferentes

Uma boa prática é após o Product Owner apresentar todos os cards, o time de desenvolvimento definir qual item é considerado o menor e partir para os demais itens usando como comparação o item de menor esforço.

Caso o time já tenha efetuado outras rodadas do Planning Poker, é permitido usar itens de Sprints anteriores como referência.

Quando é chegado o momento das “votações” é esperado que todos os membros estejam com a carta escolhida em mãos, aliás, é solicitado que todos virem as cartas ao mesmo tempo.

Se houver valores diferentes, o Scrum Master solicita para que a pessoa que escolheu o menor valor e a pessoa que escolheu o maior valor, expliquem o motivo pela qual escolheram aquela carta.

Por fim é realizada uma nova rodada para a mesma User Story até que o time entre em consenso.

Bruno, o time não entrou em consenso o que eu faço?

Bom, nesse caso é dever do Scrum Master interferir.

É importante frisar que a escolha da estimativa não se dá pela maioria ou média, isto é, a escolha se dá pelo consenso de todos na equipe.

O time é que deve decidir.

Se mesmo após o debate do time, não for chegado a um consenso, é possível que a equipe confie em um participante que já tenha desenvolvido um trabalho similar, não vendo dificuldades, ou que prefira o voto da maioria, embora informado anteriormente, é o time que deve decidir.

Carta 100 ou infinito do Planning Poker, o que significa?

Está carta é utilizada quando a User Story é tão grande e complexa que não tem como ser estimada.

Aliás, nesse caso o PO deveria ter quebrado a User Story em User Stories menores, pois a tarefa é complexa demais para ser desenvolvida em um Sprint.

Carta 0 ou 1/2 do Planning Poker

Exatamente o oposto da carta 100 ou infinito.

Neste caso o time enxerga que essa User Story é tão simples que não irá demandar tempo suficiente para atrapalhar a entrega, ou seja, pode ser feita em poucos minutos ou então que a tarefa já está pronta.

Carta interrogação do Planning Poker

Esta carta deve ser utilizada quando o time não entendeu direito o que é determinada User Story.

Assim é necessário que seja detalhado melhor a User Story, afinal, não é possível estimar sem entender.

Hora do café, cerveja ou Whatsapp

Chega uma hora que o time precisa dar uma pausa, tomar aquele café ou porque não aquela cerveja.

A carta “pausa” é um aviso que o time está cansado de tanto estimar, sugerindo continuar mais tarde.

Demais cartas (1,2,3,5,8,13,20)

Quanto menor o valor mais rápido é o tempo que o time considera para desenvolver determinada tarefa.

Como disse anteriormente, não é recomendado utilizar horas para as cartas, mas se fossemos utilizar, seria algo como carta 1 demanda em torno de 1h de desenvolvimento, carta 2 provavelmente menos de um turno de trabalho, carta 3, em torno de um turno, carta 5 em torno de 1 dia de trabalho, carta 13 uma tarefa mais complexa que demanda análise, em torno de uma semana e assim por diante, porém não recomendo que seja utilizado as cartas pensando em horas.

Benefícios do Planning Poker

• Entendimento e discussão de idéias
  Um dos principais benefícios é o real entendimento das tarefas através das discussões que ocorrem entre o time, facilitando assim o entendimento.
  O termo discussão pode parecer estranho, mas a médio prazo faz o time melhorar os conhecimentos e engajamento.

•  Se influenciar pelo mais experiente
  As cartas devem ser mostradas ao mesmo tempo, portanto fica difícil que uma pessoa mais experiente influencie na decisão.
  Dessa forma cada membro é responsável por informar a complexidade que entendeu.

•  Identificar a qualidade das User Stories
  O time pode identificar que muito dos itens apresentados estão tendo uma estimativa muito alta.
  Isso indica que o PO deve quebrar as User Stories  ou precisa detalhar mais devido as incertezas do time.

Mas porque não utilizar horas ao invés de User Story Points?

Imagine que um time diga que demora 8 horas úteis para terminar determinado ítem.

Essa informação para uma equipe comercial pode dar a entender que o time vai desenvolver em 1 dia esquecendo que dentro desse dia, sem dúvida irá ocorrer pausas para café, banheiro, reuniões e interrupções.

Quando é utilizado Story Points esse problema não acontece, visto que a estimativa de tamanho da tarefa será o mesmo.

Assim qualquer um da equipe poderá realizar a tarefa sem prejudicar o Sprint.

Outro fator é que um programador mais experiente levará menos horas que um programador menos experiente.

Modelo de baralho de Planning Poker

Elaborei especialmente para você visitante do meu blog, um baralho de Planning Poker.

Espero que gostem, aliás se precisar que o baralho seja personalizado é só entrar em contato comigo.

Baralho azul (clique aqui para baixar o PDF)

Baralho vermelho (clique aqui para baixar o PDF)

Baralho rosa (clique aqui para baixar o PDF)

Agora que você já conhece como utilizar o Planning Poker em suas estimativas, me conta aqui o que achou?

Não se esqueça de baixar os baralhos disponibilizados e utilizar no desenvolvimento dos seus produtos.

Compartilhe esse link como forma de agradecimento pelos baralhos e incentivo para eu continuar produzindo cada vez mais conteúdo.

Eu agradeço muito!!!

Se quiser receber um baralho personalizado para você ou sua empresa é só se cadastrar abaixo.