Você já parou pra pensar por que Planning Poker?
Se tem algo em que todos nós somos péssimos é em estimar, principalmente esforço.
É estranho ler isso né? Poxa, se somos tão ruins assim, porquê continuamos a estimar sem parar? Já que nosso índice de acerto é ridículo.
Tentando adivinhar o futuro
O cenário comum que existe é : Estimar todo o projeto, detalhando o máximo possível e assim se “crava” a estimativa de esforço.
Com o projeto estimado o que acontece é um verdadeiro desastre.
Tudo acontece de maneira diferente, o time descobre pedras no caminho e não consegue ter o ritmo que foi previsto.
A primeira dica é: Não tente planejar tudo de uma vez, isso é um erro.
Não conseguimos ser assertivos em estimar atividades pequenas, imagina então um projeto inteiro de uma vez. Você deve estar pensando, mas então como dou um prazo?
A resposta é simples, do mesmo jeito que você sempre fez, estime!
Mas leve em consideração que seu plano vai mudar. E o principal, não descarte o realizado ao invés disso, utilize os indicadores do realizado para calibrar as suas estimativas.
Está gostando do conteúdo? Então você gostar muito mais do que estar por vir, continue lendo, confira sobre o que ainda vamos falar:
- O cone da Incerteza
- Planning Poker: O conceito decifrado
- Fibonacci, por que escolheram logo essa sequencia?
- Os benefícios de jogar planning poker
A incerteza das estimativas
Qualquer que seja o tipo de atividade que você vai fazer, seja ela complexa demais ou simples demais vai existir uma variação da estimativa para o realizado.
Em alguns momento você pode ter uma atividade muito complexa que você estima gastar 8 horas e na realidade durante a atividade você descobre alguma técnica ou procedimento e faz ela em 2 horas. E o contrário também pode acontecer, você estimar algo em 15 minutos e gastar 2 ou 3 horas porque surgiu algo não esperado.
De uma vez por todas isso vai acontecer sempre.
O cone da Incerteza
Planning Poker – Cone da Incerteza
Em 1958 os fundadores da American Association of Cost Engineers criaram o conceito de Cone da Incerteza. Onde basicamente todas as estimativas realizadas levavam em conta ranges de incerteza.
Em 1981, Barry Boehm trouxe para o desenvolvimento de software um modelo que ele mesmo batizou como Modelo Espiral, mas esse modelo era baseado no Cone da Incerteza criado pelos engenheiros da AACE.
O Cone da Incerteza prevê que estimativas iniciais de um projeto podem varia de 0% a 400%, ou seja, a estimativa máxima pode chegar a ser 16 vezes maior que a mais baixa. Como você pode ver no gráfico de cone da incerteza abaixo:
O cone da incerteza mostra que as estimativas tendem muito a variar no inicio do projeto, mas que ao longo do tempo elas vão se estabilizando até deixarem de ser estimativas e passarem a ser realidade.
Quando você está utilizando Métodos Ágeis como o Scrum por exemplo, o que você vai ter é ao final de cada duas semanas, além de software pronto, informações de REALIZADO e isso vai te ajudar a calibrar o seu plano e ir ajustando as demais estimativas ao longo do projeto.
Planning Poker: Estime pelo tamanho relativo
Planning Poker
Como já disse, somos péssimos em estimar esforço. Mas somos bons em estimar com base no tamanho relativo.
Isso quer dizer que somos muito mais assertivos utilizando, por exemplo, P, M e G ao invés de pensar em quantas horas utilizar.
Um bom exemplo é quando vamos comprar roupas. Antes de experimentar o que você faz? Compara os tamanhos das peças e assim leva para experimentar. O interessante dessa experiência, é que ao conhecer mais a marca da roupa, na próxima compra provavelmente você irá acertar de primeira o tamanho certo.
Esse é um exemplo de dimensionamento relativo. Nós somos bons nisso!
Story Points: O que é afinal?
Para jogar Planning Poker a primeira coisa que você irá precisar é: Definir qual a unidade de medida.
Planning Poker – Story Point
Eu sugiro fortemente que você utilize Story Point. Ok, mas o que é Story Point?
Bom, talvez seja a definição mais difícil de se fazer. Quantas vezes alguém já me perguntou o que é Story Point e eu não soube explicar? Inúmeras! Eu tentava colocar Story Point no lugar da estimativa de esforço e definitivamente não é só isso.
Existem algumas definições de Story Point, mas gosto muito desse definição do Mike Cohn:
“um story point é uma junção da quantidade de esforço envolvido no desenvolvimento de uma feature, a complexidade desse desenvolvimento e o risco contido nele”.
Ficou confuso? Vou tentar simplificar: Story point é uma medida relativa de esforço, complexidade e risco. Ou seja, quando você for estimar algo leve em consideração essas três variáveis.
Como estimar com dimensionamento relativo
Estimar com base na comparação e triangulação é algo bem simples, e não exige muito esforço do time. A única coisa que é necessária é um conhecimento prévio do que vai ser desenvolvido. Veja o exemplo abaixo:
Planning Poker – Story Points
Se as estimativas não existissem, estimar em Story Point em uma Planning Poker seria algo muito simples.
Comece sempre estimando o menor itens de todos, no caso dessa planta acima é a varanda.
Varanda é de tamanho 1, se comparar com o banheiro que aparentemente é o dobro do tamanho, logo ele vai ser o tamanho de 2 Story Points.
Seguindo nessas comparações, observe que o Quarto 01 é 4 vezes maior que o banheiro, assim ele é 8 Story Points. Logo, assumimos que a sala de jantar é maior que o quarto e assim ela seria um tamanho de 13 Story Points.
Dessa maneira vamos estimar até o final, ou seja, comparando e triangulando os itens.
Perceba, que a diferença entre o Quarto e a Sala não é quase o dobro como estimamos (quarto = 8 SPs e sala 13 SPs). É exatamente nesse ponto que entra a incerteza e o risco das estimativas com Story Points.
E se a incerteza for grande como nesse exemplo, uma dica é tentar quebrar os itens (no caso a sala) em dois ou mais itens e assim tornar a incerteza menor.
Jogando o Planning Poker
Jogar o planning poker é muito simples e objetivo.
Vamos assumir que a partir de agora estamos em uma Sprint Planning e seu time é composto por 04 pessoas e iremos estimar os itens do topo do Product Backlog.
Antes algumas regras:
- Só jogam as pessoas que forem participar efetivamente da construção dos itens.
- Scrum Master deve ser o facilitador do jogo.
- Product Owner deve estar disponível para retirar dúvidas.
- Todos devem ter os baralhos de Planning Poker.
- Product Owner deve apresentar os itens priorizados ao time.
Com as regras claras vamos ao jogo.
Selecionando o menor item
Como o PO já apresentou os itens priorizados os membros do time em consenso devem definir qual o menor item dentre os selecionados para a planning. Será a partir desse menor item que o time irá começar a sua comparação.
Um sugestão é buscar um item já desenvolvido pelo time em uma sprint passada (se existir) e utilizar ele como referência de comparação. Com algo já realizado as estimativas serão mais assertivas.
Comparando e pontuando os itens
Vamos assumir que o time pontuou o menor item como 2 Story Points.
Na sequencia o time pega o próximo item do backlog, como já conhecem o que é o item irão jogar via planning poker os pontos que cada um dos membros acreditam ser o ideal para esse novo item.
Todos devem escolher sua carta sem mostrar para outra pessoa do time e jogar ao mesmo tempo.
Ao jogarem as cartas apresentadas pelos 04 membros do time foram: 5, 3, 3, 8.
Após jogarem, a pessoa que colocou o menor e maior valor apresentam os motivos que os levaram a colocarem essa carta.
Perceba, que nesse momento existe uma defesa de idéias e que as vezes os demais membros do time não se atentaram para algum detalhe.
Após a apresentação dos motivos de cada um, os membros do time jogam novamente e nesse momento são viradas as seguintes cartas: 5, 5, 5, 8
Já na segunda rodada já quase existe um consenso entre os membros do time. Apenas uma pessoa colocou diferente das demais e nesse momento é importante entender mais detalhadamente os motivos dessa diferença.
É indicado que se jogue novamente até existir o consenso, mas entenda que em alguns momentos não vai ter consenso, afinal de contas são pessoas que estão ali. Então, seu time pode definir algumas regras para determinadas situações, como essa que se apresentou.
Dicas e regras que vão te ajudar
Eu mesmo já vi algumas regras interessantes como:
Quando apenas uma pessoa estiver com a pontuação diferente, se faz a média e nesse caso daria 5,75.
Outro exemplo, que já vivenciei e acredito ser o melhor é:
Depois de jogar 3 vezes o mesmo item e o consenso não existir, pegamos o que mais de 70% do time acredita, nesse exemplo seria 5 Story Points.
Se não existir uma maioria de 70%, é o momento de quebrar o item.
Quebrar o item, vai ajudar o time a entender ainda mais profundamente a story que estão discutindo e com certeza isso vai ajudar em novas rodadas de planning poker.
Fibonacci, por que logo essa sequência?
Planning Poker – Sequencia de Fibonacci
Antes de tudo, você deve conhecer a sequência de Fibonacci, certo? Para garantir vou explicar rapidamente.
Sequência de Fibonacci, nada mais é do que a partir dos dois primeiros números 0 e 1 os seguintes serão obtidos pela soma dos antecessores.: 0, 1, 1, 2, 3, 5, 8, 13 , 21, 34 e etc….
Dessa sequência, ao se dividir qualquer número pelo anterior o resultado é um “número irracional algébrico” conhecido como número de ouro.
Ok, mas por que Fibonacci?
Se utiliza Fibonacci devido aos “saltos” que se tem entre os números, esse espaços entre eles é o que vai medir a incerteza de uma estimativa e também retirar as pessoas de irem no número do meio.
Quando o time está estimando itens menores de tamanho como 1, 2 e 3, a assertividade da estimativa tende a ser enorme. Pelo fato do item ser pequeno ele se torna mais simples de se ter o total entendimento.
Se o item está entre 5 , 8 e 13, perceba que existe um salto grande do 8 para o 13. Esse salto é justamente para provocar a discussão entre as pessoas, e evitar que escolham por exemplo, o tamanho 10, que nada mais é que o meio termo entre 8 e 13.
Resumindo, a Sequencia de Fibonacci foi escolhida para o planning poker para tirar as pessoas do status comum e discutirem em volta dos itens a serem estimados.
Os Benefícios de Jogar o Planning Poker
É comum que muitos times deixem de jogar planning poker ao longo dos projetos que estão, vejo isso acontecendo por que as pessoas acabando não entendendo os benefícios que o jogo vai trazer.
Os benefícios que o Planning Poker traz são claros e vão trazer muita informação que não devem ser descartadas pelo time.
Acabe com o Efeito Manada
Efeito Manada é o que chamo de quando alguém mais experiente vai estimar alguma atividade e por essa pessoa ser a referência do time, todos os demais acabam estimando igual ou muito próximo ao que foi jogado.
O Planning Poker definitivamente acaba com esse efeito manada, uma vez que as estimativas jogadas só são esclarecidas no momento que se viram as cartas.
Embate de ideias e conceitos
Talvez o principal benefício do planning poker são os embates de ideias.
É muito rico quando os membros do time discutem soluções e ideias para um item que está sendo estimado. O embate de ideias só vai melhorar o conhecimento do time frente ao item.
Mede a qualidade do Ready
A Planning Poker gera um indicador que poucas pessoas medem, que é a qualidade do Ready.
Se na sua planning muitos itens são quebrados, é um sinal muito forte de que as estórias que o seu Product Owner está criando estão com a cobertura de Ready baixa. E talvez seja a hora de rever como está o seu conceito de Ready e melhora-ló.
Outro indicador importante é que se as histórias estão ficando com as estimativas altas é sinal de que a incerteza está alta. E nesse caso, pode ser que seja necessário refinar melhor suas estórias.
Aprenda as melhores práticas Scrum
Planning Poker é apenas uma das práticas que você pode utilizar dentro do Scrum, existem várias outras como gestão de capacidade produtiva, modelo EVA para Daily e PEP para Sprint Review. Conhecer essas práticas vai ser um grande diferencial para sua carreira, no Scrum de Verdade você vai ter acesso a todas essas práticas e templates para aplicar o Scrum de Verdade.
Conheça agora o Scrum de Verdade e venha se tornar um Scrum Master de resultado.
Conclusão
Acredito que todo time que vá construir algo deva utilizar o Planning Poker, por ser uma prática muito simples e que gera muito engajamento das pessoas. Além de gerar alguns indicadores que podem ser extremamente uteis para o seu time.
E você o que acha do Planning Poker? Gosta de utilizar? Compartilhe com a gente a sua opinião nos comentários abaixo.
