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±9

7

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