Planning Poker An agile estimating technique for agile and Scrum teams

1. Planning PokerAn agile estimating technique for agile and Scrum teams Gestão ágil de projetos

2. 31%são cancelados 53% custam o dobro do estimado Apenas16%são completados no prazo e custo estimados * dados do CHAOS report

3. Mas por que?

4. Falta de envolvimento do usuário Requisitos e especificaçõesincompletas Falta de suporte da direção Falta de Pessoas e Recursos Falta de ESTIMATIVAS!!!

10. Scrum é também um meio de evidenciar os problemas

12. É difícil estimar tempos de execução

13. Fixara maior quantidade possível de parâmetros

14. Parâmetros de contexto Tempo, Esforço, Time Parâmetros de entrada Backlog, Prioridades, Estimativas Parâmetros de saída Objetivos, Critérios de avaliação

15. Scrum Framework

16. Time* *Tudo eu! Tudo eu!

17. 2±9 7

18. Responsabilidades: • Estimaritens do backlog • Se comprometer a entregar um incremento funcional de software • Gerenciar o próprio progresso • Auto organizados para entregar o que o PO quer

19. As cerimônias do SCRUM

21. Reunião de Estimativa: • Preparação para o Sprint Planning • Estimar baseado no tamanho, nunca em tempo • Atualizar Product Backlog com as estimativas • Importante para o PO criar o release plan

22. Artefatos

23. O Product Backlog Emergente Priorizado e estimado Maior prioridade, mais detalhes Qualquer um pode contribuir Priorização é tarefa do PO Sempre visível Alinhado ao plano de negócios

24. O Product Backlog é uma lista de todas as funcionalidades desejadas no produto, estimadas pelo time e priorizadas pelo Product Owner.

25. Estórias

26. TestáveisIndependentesNegociáveisValor parao clienteEstimáveisSmallTestáveisIndependentes

27. Exemplo de Product Backlog

29. Scrum foca em tamanhoe não em duração

30. Estimar em tamanhorelativoé mais simples

31. Planning Poker • “Planning Poker is a good way to come to a consensus without spending too much time on any one topic. It allows, or forces, people to voice their opinions, thoughts and concerns.” • Lori Schubring, Manager, Bemis Manufacturing Company

32. Planning Poker • É um método eficiente que estima o tamanho dos requisitos em times que adotam métodos ágeis (SCRUM, XP).1 • O método foi primeiramente descrito por James Grenning em 2002 e, mais tarde popularizado por Mike Cohn no livro Agile Estimating and Planning. 1 – É uma variação do método de estimativa Wideband Delphi (1940)

33. PlanningPoker • As estimativas acontecem em reuniões: • Geralmente 4 ou 8 horas. • Paticipantes: • Todos os membros do time do Scrum; • O PO somente esclarece os requisitos e não estima junto a equipe; • O ScrumMaster registra os resultados, não interferindo nas estimativas do time; • A equipe não deve ser superior a dez pessoas.

34. Tradução • Porco: • Você tem certeza que este Planning Poker funciona? Todos nós estamos quebrados. • Galinha: • - Que tal você calar a boca e distribuir as cartas Garoto do Bacon ...

35. O Processo • Cada membro do time recebe um deck de cartas: • 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ? e “pausa”.

36. O Processo • Os itens a serem estimados são lidos pelo PO ou SM • A equipe decide qual o menor item de backlog disponível.

37. O Processo • Após a estimativa inicial, esse item é marcado como “2” pontos • Serve para definir uma referência de tamanho e complexidade para ser usada nas demais estimativas. • E deve ficar registrado para uso nas futuras reuniões. • Em casos excepcionais o time pode decidir mudar esta estória de referência por uma outra.

38. O Processo • Para cada estória o SM ou PO lê a descrição e os critérios da aceitação da mesma. • São respondidos questionamentos a respeito da estória; • Manter a discussão em alto nível, não entrar em detalhes. • Tempo prefixado (timebox) nesta etapa.

39. O Processo • Cada desenvolvedor escolhe em silêncio a carta que representa sua estimativa. • O moderador pede para todos mostrarem as cartas.

40. O Processo • Se todas as estimativas convergirem, a estimativa está feita e o processo volta ao início, para um novo item. • Se houver uma grande variação na estimativa, aqueles que apresentaram o(s) maior(es) e o(s) menor(es) valor(es) se justificam. • O processo se repete até todas as estimativas convergirem.

41. Dinâmica • São Paulo • Rio Grande do Sul • Paraíba • Goiás • Amazonas • Sergipe • Roraima • Distrito Federal • Rio de Janeiro • Minas Gerais • Santa Catarina • Mato Grosso • Pernambuco • Rondônia • Acre • Bahia

42. ?

43. http://delicious.com/macaubas • http://delicious.com/marcospereira • http://scrumalliance.org • http://br.groups.yahoo.com/group/scrum-brasil/ • http://macaubas.com • http://marcospereira.wordpress.com/

44. http://blogdoabu.blogspot.com/2008/11/planning-poker.html • http://infoblogs.com.br/view.action?contentId=18765&Play-Estimate-Plan-Ferramenta-agil-para-simular-Planning-Poker.html • http://queroseragil.files.wordpress.com/2007/10/scrum_reference.pdf • http://planningpoker.com/ • http://netfeijao.blogspot.com/2008/10/estimativas-geis-planning-poker.html

45. http://www.oncast.com.br/blog/?tag=planning-poker • http://www.planningpoker.com/ • http://en.wikipedia.org/wiki/Planning_poker • http://www.planningpoker.com/detail.html