Estimativa de tempo utilizando Planning Poker

Estimativa-de-tempo-utilizando-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  5 benefícios de utilizar um modelo de EAP no detalhamento do escopo do seu projeto

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  Técnica do Valor Agregado: Breve História

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.

CTA-Gestão-de-tempo-em-projetos-4-dicas-para-não-perder-o-foco

Email Marketing by E-goi

Deixe uma resposta

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