planning poker an agile estimating technique for agile and scrum teams
DESCRIPTION
Planning Poker An agile estimating technique for agile and Scrum teams. Gestã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 - PowerPoint PPT PresentationTRANSCRIPT
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