Planning Poker é uma técnica rápida para o time estimar o que realizará em breve, discutindo e entendendo melhor cada item a ser criado ou desenvolvido. Tem sua origem no eXtreme Programming (XP), numa situação em que as estimativas das histórias de usuários estavam demorando muito por discussões intermináveis de duas pessoas, além do mais o restante do time não estava sendo envolvido.
Esta técnica foi criada por James W. Grenning, um dos signatários do manifesto ágil, publicada em abril de 2002 no artigo “Planning Poker or How to avoid analysis paralysis while release planning”. Mike Cohn refinou a técnica e a publicou em seu livro Agile Estimating and Planning (2005). Foi incorporada em treinamentos de Scrum e se tornou muito popular.
É utilizada no início de cada iteração ou sprint, durante a reunião de planejamento para estimar as histórias de usuário. Também pode ser utilizada para estimar épicos ou funcionalidades de um modo mais macro, e em reuniões de refinamento de backlog. A pessoa de negócio (cliente ou Product Owner) lê e explica a história de usuário. O time de desenvolvimento então discute a história e a estima com uma carta do Planning Poker.
Como benefícios, Planning Poker
- é mais rápida que abordagens tradicionais de estimativa, mantendo um bom resultado;
- auxilia a prevenir discussões em “loop infinito” (analysis paralysis);
- mostra os requisitos que ainda não estão prontos para desenvolvimento (Definition of Ready);
- previne também que apenas uma pessoa faça as estimativas para o restante do time;
- cria engajamento e senso de pertencimento ao time por estar tendo discussões abertas e todos trazendo suas próprias estimativas.
Conversação e consenso
Para estimativas ágeis, conversação e consenso são essenciais. O time deve discutir cada história de usuário (ou qualquer outro tipo de requisito de usuário). Quando o time já conhecer bem histórias de usuário semelhantes, haverá um consenso rápido da estimativa, com pouca discussão. De outro modo, quando o time não tiver experiência em desenvolver a história de usuário, deverá haver mais conversação para entendimento e consenso.
Estimativas são estimativas, nem sempre estarão corretas prevendo o futuro. Algumas estimativas serão menores, outras maiores, porém na média funcionam relativamente bem. A inteligência coletiva auxilia também na melhor precisão das estimativas.
Planning Poker passo a passo
- Cada integrante do time de desenvolvimento tem um baralho de Planning Poker. Caso não haja tal baralho, pode se utilizar cartões de papel em branco para anotar as estimativas conforme necessário.
- As estimativas devem seguir a sequẽncia de Fibonacci (0, ½, 1, 2, 3, 5, 8, 13, …).
- O cliente/product owner lê e apresenta a história de usuário (ou o requisito de usuário em outros formatos).
- O time de desenvolvimento discute a história de usuário com o objetivo de entender o requisito.
- Cada integrante do time decide uma estimativa, colocando a carta virada para baixo, escondendo o número da estimativa.
- Quanto todos integrantes do time colocarem suas estimativas na mesa, viram-se as cartas apresentando as estimativas no mesmo instante. Eis a origem do nome “poker”.
- Caso as cartas tenham os mesmos valores, a estimativa está pronta. Vá para a próxima história de usuário, se houver. Se não houver, a sessão de Planning Poker finaliza.
- Caso não sejam iguais, havendo extremos ou discrepância significativa, todos que estimaram os extremos discutem seus pontos de vista. Após a discussão, o processo de poker se repete, com cada integrante do time jogando uma carta de estimativa.
Exemplos
- Exemplo A. O cliente apresenta uma história de usuário A. Os integrantes do time discutem e jogam as cartas 5, 2, 5, 3, 8, 5. As pessoas que jogaram as cartas nos extremos 3 e 8 discutem seus pontos de vista. O time joga novamente as cartas 5, 5, 5, 5, 5 e 5. A história de usuário está estimada em 5 user story points.
- Exemplo B. O cliente apresenta uma história de usuário B. Os integrantes do time jogam as cartas 3, 3, 3, 2, 3, 3. A pessoa que jogou a carta 2 explica seu ponto de vista (já existe um componente pronto a ser reutilizado que facilita a implementação). O time joga novamente as cartas 2, 2, 2, 2, 2 e 2. A história de usuário está estimada em 2 user story points.
- Exemplo C. O cliente apresenta uma história de usuário C. Os integrantes do time jogam as cartas 1, 1, 1, 1, 1, 1 (essa é uma história de usuário bastante simples de implementar). A história de usuário está estimada em 1 user story point.
Dicas importantes
- Tenha um facilitador do Planning Poker. Pode ser qualquer pessoa presente, inclusive algum integrante do time, preferencialmente que já tenha conheça ou tenha experiência com a técnica.
- Se for a primeira vez que o time utilize Planning Poker, faça algumas rodadas de simulação com diferentes histórias de usuário. Assim o time pode entender o processo do jogo, e já ir entendendo o que é uma história de usuário de diferentes estimativas.
- Ajude o time a encontrar uma história de usuário que seja pequena o suficiente para ter a estimativa 1. As outras estimativas serão, em média, proporcionais a esta.
- Quando as cartas jogadas forem diferentes, não faça a média da estimativa. A conversação sobre os pontos de vista de cada estimativa é essencial, e também pode mudar significativamente a estimativa.
- Quando houver muita discrepância nas estimativas, faça com que pelo menos as pessoas que colocaram a menor e a maior estimativas apresentem e discutem suas perspectivas.
- Faça outra rodada quando não houver um consenso rápido.
- Se houver muita discussão técnica e não chegar a um consenso, faça uma nova rodada. Se o consenso não acontecer novamente, escolha a solução mais simples e de menor estimativa (simplicidade é um dos valores do XP).
- Quando há muita incerteza técnica, planeje um spike para entender como a história será desenvolvida. E então somente na próxima reunião de planejamento apresente o resultado do spike.
- O time pode estimar a tarefa de spike. Também pode estimar bugs a corrigir, além de dívidas técnicas a resolver.
- Planning poker demanda o engajamento da pessoa de negócio (cliente, PO) a entender e explicar cada requisito a ser desenvolvido pelo time.
- Busque que sempre a pessoa de negócio esteja presente na sessão de Planning Poker, exceto se o time já conheça bem as histórias de usuário.
- Não há problema se nas primeiras sessões de Planning Poker o time demore um pouco mais ao estimar. O time vai ganhando experiência e o consenso das histórias de usuário vai acontecer mais rapidamente com o tempo.
- O time ganha tempo colocando o foco e tempo em histórias de usuário mais desconhecidas e não nas que já entendem e concordam.
- Caso não tenha um baralho de Planning Poker, utilize cartões em branco para escrever as estimativas.
- Planning poker é bastante útil para estimativas para a próxima iteração. Quando houver diversas dezenas ou centenas de itens para estimar, busque utilizar outras técnicas de estimativas mais rápidas porém menos precisas (tal como a técnica bucket system).
- Utilize a sequência de Fibonacci (1, 2, 3, 5, 8, 13, …), pois acompanha a certeza das estimativas. Estimativas mais certas serão as menores, então a sequência tem menos diferenças entre cada número. Estimativas maiores são mais incertas, então a sequẽncia tem mais diferenças entre os números.
- Uma noção de estimativa é que 1 e 2 são histórias de usuário pequenas (excelentes), 3 e 5 histórias de tamanho médio (ok), 8 e 13 tamanho grande (busque quebrar). E maior que isso são tamanhos inviáveis para uma iteração/sprint, é necessário dividir essa história de usuário, que provavelmente já é um épico ou uma funcionalidade completa.
- Caso haja itens não planejados durante a iteração/sprint, cada pessoa que desenvolver estes itens pode anotar a estimativa aproximada que teria sido, assim mantém a transparência e a medida de velocidade do time.
- A estimativa da história de usuário deve ser refletida em esforço, tempo, complexidade, conhecimento, risco e qualquer outro fator que influenciar no desenvolvimento da história.
- Nunca, absolutamente nunca, adicione um buffer ou margem de segurança (“gordura”) na estimativa da história de usuário.
User story points ou tempo ideal?
Busque utilizar user story points, e não medidas baseadas em tempo, tal como horas, turnos ou dias ideais. Medidas baseadas em tempo dependem das habilidades e da experiência de cada integrante do time. Além de que estimativas em tempo podem se tornar prazos finais, fazendo com que o time comece a colocar margens de segurança nas estimativas.
Reflita… Se houver estimativas baseadas em tempo, poderá haver questionamento sobre a produtividade do time “por que o time está estimando apenas 70% do tempo dele?”. O time não vai se sentir confortável em dar estimativas, e o efeito pode ser que o time coloque mais margem de segurança.
Outro problema é a Lei de Parkinson “O trabalho se expande de modo a preencher o tempo disponível para a sua realização”. Essa Lei faz com que todo o tempo estimado seja utilizado, mesmo que menos tempo possa ser suficiente, o desenvolvedor vai buscar fazer mais coisas do que o necessário (YAGNI!).
Outro porém é a Síndrome do Estudante. Conhecemos muito bem. Por ter um prazo com uma margem de segurança, o maior esforço é deixado para o final do prazo, correndo o risco até de ser utilizado mais tempo que fosse suficiente.
Indo além do Planning Poker com eXtreme Programming
Para a técnica de Planning Poker ser mais eficiente, conheça mais sobre os valores, princípios e técnicas do eXtreme Programming, tal como jogo do planejamento, histórias de usuário, critérios de aceitação, TDD e muito mais. Recomendo a leitura do livro que escrevi eXtreme Programming Práticas para o dia a dia no desenvolvimento ágil de software. Daniel Wildt, Dionatan Moura, Guilherme Lacerda, Rafael Helm. Editora Casa do Código (2015) https://www.casadocodigo.com.br/products/livro-xp-extreme-programming
Compartilhe a técnica com seu time!
Dionatan Moura 
Você precisa fazer login para comentar.