Planning Poker An agile estimating technique for agile and Scrum teams
description
Transcript of Planning Poker An agile estimating technique for agile and Scrum teams
Planning Poker An agile estimating technique
for agile and Scrum teamsGestão ágil de projetos
31% são cancelados 53% custam o dobro do
estimado
Apenas 16% são completados no prazo e custo estimados
* dados do CHAOS report
Mas por que?
Falta de envolvimento do usuário
Requisitos e especificações incompletas
Falta de suporte da direção
Falta de Pessoas e Recursos
Falta de ESTIMATIVAS!!!
Scrum é também um meio de evidenciar os
problemas
É difícil estimar tempos de execução
Fixar a maior quantidade possível de parâmetros
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
Papéis
• Scrum Master• Product Owner• Team
Artefatos
• Product Backlog• Sprint Backlog• Burnup/
Burndown Charts
Reuniões
• Estimativas• Planning• Daily Scrum• Review &
Retrospective
Scrum Framework
Time*
*Tudo eu! Tudo eu!
2±97
Responsabilidades:• Estimar itens 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
As cerimônias do SCRUM
Estimation Meeting*
Sprint Planning• S
print Planning 1
• Sprint Planning 2
Daily Scrum
Sprint Review
Sprint Retrospective
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
Artefatos
O Product BacklogEmergente
Priorizado e estimadoMaior prioridade, mais detalhes
Qualquer um pode contribuirPriorização é tarefa do PO
Sempre visívelAlinhado ao plano de negócios
O Product Backlog é uma lista de todas as funcionalidades desejadas no produto,
estimadas pelo time e priorizadas peloProduct Owner.
Estórias
TestáveisIndependentesNegociáveisValor para o clienteEstimáveisSmallTestáveisIndependentes
Exemplo de Product Backlog
Scrum foca em
tamanho e não
em duração
Estimar em tamanho relativo é mais simples
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
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)
Planning Poker
• 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 Scrum Master registra os resultados, não interferindo
nas estimativas do time;• A equipe não deve ser superior a dez pessoas.
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 ...
O Processo
1. Cada membro do time recebe um deck de cartas: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ? e “pausa”.
O Processo
2. Os itens a serem estimados são lidos pelo PO ou SM A equipe decide qual o menor item de backlog
disponível.
O Processo
3. 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.
O Processo
4. 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.
O Processo
5. Cada desenvolvedor escolhe em silêncio a carta que representa sua estimativa. O moderador pede para todos mostrarem as
cartas.
O Processo
6. 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.
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
?
• 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/
• 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
• 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