Em qualquer projeto temos sempre a mesma dificuldade: Como vou saber quanto tempo vou levar para alguma atividade? Será que devo começar sem saber e no meio do caminho falar quanto tempo falta? Pode ser software, hardware ou construção. Até os profissionais mais experientes possuem dificuldades em estimar o próprio trabalho.
Felizmente existem diversas técnicas que podem nos ajudar e uma delas é o Planning Poker. Neste artigo vamos entender como utilizar esta técnica.
Antes de tudo: Estimar não é desperdício de tempo! Muitos profissionais acreditam que passar algumas horas ou dias estimando um trabalho é perda de tempo, que o certo é ‘sair fazendo’ e adivinhar a estimativa com base apenas neste esforço inicial.
Porém, precisamos estimar! Seu cliente precisa de um prazo, seu gestor de um orçamento. A equipe de marketing precisa estruturar o lançamento do seu produto. E felizmente com o Planning Poker você pode transformar semanas de trabalho em estimativas em apenas algumas horas.
O que é Planning Poker?
Planning Poker é uma técnica do Scrum que permite ao time do projeto gerar estimativas rapidamente. Nesta técnica não precisamos detalhar ao máximo as atividades definindo o tempo em horas para cada tarefa. O trabalho é feito em cima das user stories do projeto, onde a equipe com sua experiência registra o quanto um recurso, uma user story, é maior que a outra.
Antes de tudo, você precisa ter em mãos a lista de user stories representando o escopo do seu projeto. Com a lista criada, o time se reúne para trabalhar nestas estimativas.
Estas estimativas são feitas utilizando Story Points, que representam um valor abstrato de tamanho. Não é uma estimativa em horas, apesar de muitos converterem para tal. Exemplo: 1 Story Point = 4 horas de trabalho ideal. Não recomendo já que isso tira a característica do Story Point: Ser abstrato para mostrar o tamanho relativo da user story em comparação com as outras user stories da lista.
Cada membro tem em mãos um baralho de cartas, cada um com um valor diferente de Story Point. Os valores são: 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40 e 100. Também existem as cartas ‘interrogação’, ‘infinito’ e em alguns modelos, a carta ‘café’. Explicarei sobre elas adiante.
Como ele funciona
- Alguém da equipe lê a user story em voz alta e, se possível, apresenta a mesma em um slide na TV ou escreve no quadro branco.
- A equipe discute o critério de aceitação (definido pelo Product Owner) e tiram todas as dúvidas sobre ela.
- Cada membro, exceto o Product Owner, decide individualmente quantos Story Points e seleciona a carta do seu baralho, sem mostrar aos demais.
- Quando todos os membros já estiverem com a carta escolhida em mãos, todos viram as cartas ao mesmo tempo.
- Caso os valores sejam diferentes, cada um apresenta uma justificativa, geralmente do valor mais alto ao mais baixo.
- Depois o time vota novamente até que o grupo chegue a um acordo.
Mas e se a equipe não conseguir chegar a um acordo?
O Scrum Master pode interferir. Vamos supor que você tenha 5 participantes votando, insistindo nos seguintes valores:
- A: 5
- B: 5
- C: 5
- D: 8
- E: 2
O Scrum Master, com base nos argumentos, pode solicitar ao time que entre em acordo de qual destas estimativas utilizar. A escolha NÃO é sempre pela maioria ou pela média! A equipe pode confiar no participante ‘E’ que diz já ter desenvolvido o mesmo trabalho da user story e não vê dificuldades ou preferir o voto da maioria. O time decide!
Não se esqueçam de estimar também as novas user stories que vão surgindo ao longo do projeto. Quando a user story surgir, faça a estimativa usando Planning Poker, não deixe para depois.
Porque usar Story Points ao invés de volume de Horas?
Em um projeto, as partes interessadas costumam ter dificuldades para entender o conceito de horas ou dias ‘ideais”.
Se seu time diz que levará ’30 dias ideais’ para concluir uma user story, os demais envolvidos no projeto, principalmente os relacionados à área de negócio, costumam esquecer a parte do ‘ideal’ e lembrar apenas dos 30 dias, falando “oba, eles vão terminar o trabalho em apenas 30 dias”.
Outro problema é a capacidade técnica da equipe. Enquanto um membro mais experiente pode dizer que termina o desenvolvimento da user story em apenas 1 hora, um menos experiente pode informar que levará 10.
O uso de story points elimina este problema, pois separamos o tamanho da user story do tempo que realmente levará para desenvolver. Desta forma a equipe conseguirá estimar com mais eficiência o tamanho relativo das user stories.
Em tempo: ‘Horas Ideais’ são as horas efetivamente trabalhadas em uma atividade. Se considerarmos que um dia tem 8 horas úteis, podemos ter em média 5 ou 6 horas ideias, descontando por exemplo: reuniões, café, tempo de ida ao banheiro, momentos de socialização, etc. Considere horas ideias as efetivamente trabalhadas na atividade, sem interrupções. Esqueça portanto aquele conceito que 1 mês possui 160 horas disponíveis.
Onde posso conseguir um baralho de Planning Poker?
Você encontra diversos modelos para download na internet, além de alguns sites vendendo modelos impressos.
Clique aqui e faça o download de um modelo simples em PDF para você mesmo imprimir e começar a estimar seus projetos ainda hoje!
Como utilizar a carta Zero (0), Infinito, Interrogação(?) e “Café”?
Zero (0)
As vezes a user story é tão simples que a equipe não quer prejudicar a capacidade de entrega da sprint com ela. Por exemplo: Uma user story diz que precisamos mover o botão ‘salvar’ da tela do aplicativo da direita para a esquerda. A equipe acredita que isso pode ser feito em poucos minutos. Então ao invés de usar a carta 1/2, utiliza a carta 0.
Infinito
Praticamente o oposto. A user story é tão grande que não se encaixa na carta “100”. A equipe não se sente confortável em estimar então utiliza a carta ‘infinito’. A user story precisa ser melhor entendida ou ainda quebrada em user stories menores.
Interrogação (?)
Como dito antes, a equipe precisa discutir cada user story antes da votação para que todos os membros entendam do que a mesma se trata. Porém as vezes um membro da equipe não faz idéia de como estimar. Então ele utiliza a carta ‘Interrogação(?)’ para sinalizar que precisa discutir mais a user story até que todo o time tenha realmente entendido do que ela se trata.
Carta Café
Ninguém é de ferro! Esta carta serve para sinalizar que alguém da sua equipe precisa fazer uma pausa. O Scrum Master pode ajudar a definir o tempo de intervalo e, claro, providenciar comida e bebida para a reunião 🙂
Conclusão
A técnica do Planning Poker ajudará sua equipe a não ficar dias estimando um projeto. Fornece resultados rápidos com um bom nível de precisão. E ainda vem com um benefício adicional: Estimula sua equipe a discutir cada user story, gerando maior entendimento do projeto como um todo, acelerando o desenvolvimento já que todos sabem o que estão fazendo e onde querem chegar. Além disso aumenta a chance de acertarmos nas estimativas, uma vez que as mesmas são criadas pelas opiniões individuais da equipe e não por um membro experiente isolado.
Gostou do artigo? Tem dúvidas, sugestões ou comentários? Deixe abaixo nos comentários! Obrigado pela leitura!
Publicação Original: http://www.vignado.com.br/?p=591
6 Comentários
Olá Alexandre, venho estudando seus materiais e são maravilhosos, meus parabéns!
Tentei baixar o arquivo mencionado nesse artigo, mas o mesmo não está mais disponível, poderia disponibilizar ele novamente?
Obrigado
Alexandre, muito bom artigo !!
Acho que Entendi o conceito de definir o tamanho dw.uma User Story por story points, mas xomo vamos chegar ao prazo da equipe sem converter em horas ?
Obrigado…
Olá Wesley! Desculpe a demora, não vi seu comentário!
Então, tive um problema com meu site antigo e precisei refazer tudo. Alguns arquivos foram perdidos (ou não localizados até o momento!)
Mas fique tranquilo que o modelo era simples, nada diferente do que já existe pronto na internet ok?
Segue abaixo o link de um parecido, muito bom.
Obrigado pela leitura!
http://mbf-iut.i3s.unice.fr/lib/exe/fetch.php?media=2015_2016:s3:methodo:td:pdf-planning-poker-for-print1.pdf
Olá André!
Então, no começo é dificil quebrar essa barreira de horas, mas é justamente nisso que o Poker Planning ajudará.
Se você tem apenas um desenvolvedor, realmente é dificil mas em um time multifuncional, através da votação, a carga de trabalho em pontos será melhor estimada. E com histórico, você saberá a capacidade de entrega do time em pontos (já que cada desenvolvedor tem um ritmo e estimaria em ‘horas’ diferente pro mesmo desenvolvimento).
Após o planejamento você terá idéia de quantas sprints precisará e o histórico vai servir pra alinhar o quanto a equipe está sabendo estimar e pontuar usando o poker planning (ou outro método de pontos). Lembrando que quem definirá o prazo (quantidade de sprints) será a capacidade de entrega (wip) + pontuação do backlog pelo poker planning.
O poker planning também quebra a barreira das horas, já que tira a subjetividade do volume de trabalho (lembrando do do conceito de horas ideais X horas disponíveis), já que os pontos são, de fato, ideais por assim dizer. Isso, claro, se a equipe tiver a maturidade de votar/pontuar pensando em pontos (ou horas se for o caso) efetiva, desconsiderando pausas, café, banheiro, intervalos, etc. Isso leva tempo.
Espero ter ajudado você a entender melhor!
Abraços!
Eu fiquei com a mesma dúvida do André Aquino. É praxe, o cliente solicitar uma estimativa e passar a ele em pontos, fica estranho, até porque, o cliente não conhece os métodos ágeis. O Planning Poker é sensacional, o seu artigo é um conteúdo de extrema relevância, mas ainda sinto a falta de converter essa pontuação do Planning Poker em horas (tempo).
Pelo que eu entendi, o Planning Poker identifica o esforço, baseado no conhecimento, experiência e desenvolvtura de cada profissional, mas o resultado deveria me levar (Srum Master) a conversão dessa estimativa de esforço a uma estimativa de tempo.
Olá Paulo!
Entendo sua dúvida! Mas veja que no Planning Poker usualmente não podemos repetir a pontuação das histórias. Temos que estimar por exemplo 5 histórias e elas nunca terão a mesma pontuação, porém podem durar o mesmo tempo, ou isso ser irrelevante desde que seja entregue dentro da sprint. Além disso, na votação, se houver muita divergência entre os membros, significa que a história precisa ser melhor detalhada ou até mesmo quebrada. O objetivo da pontuação é identificar a dificuldade da história.
Então, uma história pode ter dificuldade de “2 pontos” enquanto outra pode ter de “4 pontos” e não necessariamente a segunda levar o dobro do tempo ou dobro de custo. Podem por exemplo serem feitas por equipes de Devs diferentes. A primeira história pode levar 1 dia e a segunda 3 dias.
Com a maturidade no time, claro, eles saberão +/- quanto dura cada ponto em cada equipe e poderão estimar o custo e prazo melhor, mas tudo depende de quanta sinergia este grupo terá.
O grupo saberá quantos pontos podem entregar aproximadamente por sprint e saberão que, de acordo com a percepção deles em relação a esforço, quanto podem desenvolver em um mês.