Planning Poker
An agile estimating technique
for agile and Scrum teams
Gestão ágil de projetos
31% são
cancelados
53% custam o
estimado
Apenas
dobro do
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
Scrum Framework
Reuniões
• Estimativas
• Planning
• Daily Scrum
• Review & Retrospective
Artefatos
• Product Backlog
• Sprint Backlog
• Burnup/Burndown
Charts
Papéis
• Scrum Master
• Product Owner
• Team
Time*
*Tudo eu! Tudo eu!
2±9
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
• Sprint 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 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
O Product Backlog é uma lista de todas
as funcionalidades desejadas no produto,
estimadas pelo time e priorizadas pelo
Product Owner.
Estórias
EstimáveisSmallTestáveisIndepen
o cliente
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/plannin
g-poker.html
• http://infoblogs.com.br/view.action?contentId=1
8765&Play-Estimate-Plan-Ferramenta-agil-parasimular-Planning-Poker.html
• http://queroseragil.files.wordpress.com/2007/10
/scrum_reference.pdf
• http://planningpoker.com/
• http://netfeijao.blogspot.com/2008/10/estimativ
as-geis-planning-poker.html
• http://www.oncast.com.br/blog/?tag=plannin
g-poker
• http://www.planningpoker.com/
• http://en.wikipedia.org/wiki/Planning_poker
• http://www.planningpoker.com/detail.html