Estimativa de tempo utilizando Planning Poker

planning poker

Uma forma de estimativa bastante difundida e aplicada com métodos ágeis é o Planning Poker. É uma estimativa de tamanho baseada na comparação entre funcionalidades.

Como funciona o Planning Poker?

O método utiliza os Números de Fibonacci como referência. Estes números são formados por uma sequência onde o próximo número é a soma dos dois números anteriores.

O início da sequência é 0, 1.

Então somando os dois primeiros, o número seguinte será o 1. Temos então 0, 1, 1.

Repetindo isto, teremos o 2, gerando 0, 1, 1, 2.

Continuando a repetição, teremos a sequência: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89 e assim sucessivamente.

Para o Planning Poker podemos usar 1, 2, 3, 5, 8, 13, 21, 34. O último número aqui vai depender das informações seguintes de entendimento da técnica.

O uso desta sequência de números tem a finalidade de explicitar que quanto menor a funcionalidade que estamos desenvolvendo, menor a variação possível da estimativa.

Uma história de 2 pontos tende a variar de 1 a 3 pontos. Uma estimativa de 13 pontos tende a oscilar entre 8 e 21 pontos. Ou seja, é melhor trabalharmos com histórias de tamanhos menores por que elas tem uma possibilidade de variação de tamanho menor. Uma variação entre 8 e 21 pontos pode afetar muito o andamento de uma Sprint, já uma variação entre 1 e 3 pontos é mais facilmente administrada.

Temos então uma primeira estrutura da técnica de estimativa com Planning Poker que é o uso dos Números de Fibonacci, devendo considerar que quanto maiores as estimativas, maiores serão as variações possíveis.

Agora precisamos entender como relacionar o tamanho das coisas.

Se estivermos estimando requisitos de software e utilizando User Story como técnica de requisitos, vamos escolher uma história que seja pequena, simples e facilmente compreendida pelo time de desenvolvimento.

A esta história vamos dar o tamanho 2.

Este tamanho 2 será uma base de comparação para estimar o tamanho das outras histórias.

Por exemplo: vamos estimar o tamanho de algumas frutas.

Escolhemos o limão como referência, então o tamanho dele será 2.

Leia também  Afinal, o que é Project Management?

Ainda que um limão possa ter variações de tamanho, compreendemos que ele deve ficar entre os tamanhos 1 e 3.

Agora vamos comparar o limão com uma laranja. Qual seria o tamanho da laranja?

Vamos considerar que é 5. Ainda que a laranja possa ter tamanhos diferentes, entendemos que seu tamanho ficará entre 3 e 8.

Agora vamos fazer a comparação com um morango. Como os morangos em geral são menores que um limão, vamos dar a ele o tamanho 1.

Este é o motivo de definirmos o tamanho 2 para a história de referência: é que sempre podem existir situações menores e estas é que terão tamanho 1.

Nunca teremos histórias de tamanho quebrado como 0,5 ou 1,5. Os tamanhos devem seguir os números de Fibonacci.

Se houver alguma situação muito pequena, avalie se é possível juntar com outra história. Caso contrário, o tamanho dela terá que ser 1.

Como último exemplo, vamos comparar agora o limão com um abacaxi.

Podemos perceber que do limão para o abacaxi a diferença de tamanho é bem maior. Também existe um agravante: um abacaxi pode ter muito mais variações de tamanho.

No nosso caso, vamos dar ao nosso abacaxi o tamanho 21.

Esta é uma situação perigosa pois estimamos o tamanho de algo maior e com muito mais possibilidade de variação.

Nestes casos é prudente solicitar ao Product Owner que quebre esta história em tamanhos menores, mais facilmente compreensíveis, estimáveis e entregáveis.

Se adotarmos a regra que histórias de 21 pontos não devem ser desenvolvidas devido a sua complexidade, temos agora quais seriam as nossas cartas para o Planning Poker: 1, 2, 3, 5, 8, 13 e 21, considerando que histórias com tamanho 21 deverão ser quebradas em duas ou mais.

A estas cartas podemos acrescentar ainda uma carta de “?” que significa que não foi possível compreender o que precisa ser desenvolvido, seja em termos de negócio ou em termos técnicos.

Chegou a hora de jogar.

Agora temos o baralho e uma história de referência. O Product Owner explica a história a ser estimada. Todos discutem e tiram suas dúvidas até que o entendimento seja considerado adequado.

Leia também  Produtividade em Blocos - Conheça a Pomodoro Technique

Após este entendimento, cada um escolhe uma carta sem demonstrar aos outros membros da equipe para evitar que sua estimativa influencie a estimativa dos demais.

Esta influência pode ser causada, por exemplo, pela percepção da equipe de que determinada pessoa tem um conhecimento muito bom sobre o assunto e que se ele estiver estimando um tamanho, provavelmente aquele tamanho é o correto.

Após todos apresentarem suas cartas, as situações possíveis são as seguintes:
  • Todos colocam o mesmo tamanho -> neste caso a estimativa pode ser considerada concluída;
  • Alguém coloca a carta “?” -> deve-se voltar a discutir a história
  • Chega-se a conclusão que a história tem tamanho 21 ou mais -> o Product Owner deve quebra-la em histórias menores;
  • Existem cartas divergentes -> cada um deve ser ouvido para explicar por que acha o tamanho maior ou menor. Após isto joga-se novamente.
Na última situação acima, deve-se discutir e continuar jogando até que todo o time apresente a mesma carta em uma rodada.
Esta técnica é bastante simples e ajuda a criar uma referência de tamanho e produtividade da equipe. Em duas ou três sprints é possível perceber os resultados do processo de estimativa.

Gestão de Tempo em Projetos: 4 dicas essenciais

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

20 − dezenove =

Consultoria Conduzimos gestores e suas equipes à conquista de resultados! Outsourcing Alocação de profissionais especializados e de alta maturidade Capacitação Treinamentos In Company