Planning Poker An agile estimating technique for agile and Scrum teams Gestão ágil de projetos

53% custam o dobro do estimado 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?

Requisitos e especificações incompletas 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 Scrum tenta deixar os problemas evidentes para percebermos que o projeto vai falhar. Ou, claro, corrigir os erros para que o projeto ande melhor.

É difícil estimar tempos de execução

Fixar a maior quantidade possível de parâmetros

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

Scrum Framework Papéis Scrum Master Product Owner Team Artefatos Product Backlog Sprint Backlog Burnup/Burndown Charts Reuniões Estimativas Planning Daily Scrum Review & Retrospective

Time* *Tudo eu! Tudo eu!

2±9 7 Times pequenos são mais produtivos que times grandes, por causa da quantidade de vias de comunicação existente entre os membros do grupo. Se o seu time for maior que o recomendado, então ele deve se dividir em dois e o trabalho de ambos ser sincronizado.

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 decisões de desenvolvimento são feitas pelo time. Ou seja, o time tem autoridade para fazer o que seja necessário para cumprir seus compromissos

As cerimônias do SCRUM

Estimation Meeting* Sprint Planning 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 Priorizado e estimado Emergente 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. O product backlog é o coração do Scrum. É aqui que tudo começa. O product backlog é basicamente uma lista de requisitos, estórias, Coisas que o cliente deseja, descritas utilizando a terminologia do cliente.

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 Cada membro do time recebe um deck de cartas: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ? e “pausa”.

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.

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.

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.

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

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.

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