PLANNING POKER E SCRUM POKER – TUDO O QUE PRECISA DE SABER

Oi, esta semana vou discutir Planning Poker ou Scrum Poker; estratégias que usam estimativas baseadas no consenso. Equipas Agile em todo o mundo usam a técnica de planning poker para fazer uma estimativa dos seus product backlogs. O Scrum Poker pode ser usado com story points, ideal days ou qualquer outra unidade de estimativa.

O Planning Poker ou Scrum Poker junta a opinião de múltiplos especialistas para chegar a uma estimativa agile de um projecto. Este tipo de planeamento agile inclui todos: programadores, testes, engenheiros de base de dados, analistas, user interaction designers e todo o outro pessoal envolvido no projecto.

Como estes membros da equipa representam todas as disciplinas num projecto de software, são os mais indicados para a tarefa de estimativa.

Como é que o Planning Poker Funciona

Uma sessão de planning poker ou scrum poker envolve product owners ou clientes e editores. A sessão começa com cada estimador tendo um baralho de cartas, com valores que variam em sequência. Recomendamos o seguinte: 0, 1, 2, 3, 5, 8, 13, 20, 40 e 100.

Estes valores representam o número de story points, ideal days ou outras unidades nas quais a equipa irá estimar. O product owner ou cliente vai ler uma agile user story ou descrever uma funcionalidade aos estimadores.

Os estimadores discutem a funcionalidade e, se necessário, fazem perguntas ao product owner. Quando os estimadores acabarem esta discussão, cada um selecciona uma carta privadamente para respresentar a sua estimativa. A seguir, as cartas são reveladas simultaneamente.

Se os estimadores selecionarem o mesmo valor, esse número torna-se a estimativa. Se os valores forem diferentes, os estimadores discutem a sua análise racional.

Aqueles que escolheram os valores mais altos ou mais baixos devem partilhar o seu raciocínio com o grupo, antes que cada estimador seleccione outra carta de estimativa, repetindo o processo.

Os estimadores continuam o processo de poker planning até se chegar a um consenso relativamente ao valor. Se não concordarem, estes podem optar por adiar/deferir a estimativa agile e o planeamento de um determinado item, ficando dependentes de informação adicional.

Quando nos devemos empreender no Planning Poker (Ou Scrum Poker)

A maioria das equipas terá uma sessão de poker planning logo após o product backlog inicial estar escrito. Essas sessões, que podem levar vários dias, servem para criar estimativas iniciais que são úteis no escopo ou dimensionamento do projecto.

Como os itens de product backlog – muitas vezes, em forma de user stories – continuam a ser adicionados ao longo de todo o projecto, a maior parte das equipas considera útil conduzir sessões de estimativa e planeamento agile subsequentes, por cada iteração.

São tipicamente realizadas poucos dias antes do fim da iteração e imediatamente a seguir a um daily standup, pois a equipa ainda está junta.

Dicas para Planning Poker em Scrum

As seguintes dicas ajudam as equipas a lidar com desafios comuns do poker planning em Scrum:

• Manter as discussões produtivas: Uma ampulheta de dois minutos é uma ferramenta útil usada para ensinar as equipas a fazerem estimativas de forma mais rápida. Para a usar, ela é colocada, quando alguém no grupo inicia uma ronda. Quando a areia acaba, joga-se a ronda seguinte do planning poker.
• Dividir em sessões mais pequenas: O ideal é, sempre que possível, dividir um grupo maior em sub-equipas mais pequenas. Essa é uma boa opção para conduzir sessões onde há muitas stories a estimar; muitas vezes, ocorrendo no início de um novo projecto.
• Quando jogar:  Tipicamente, as equipas de estimativas precisam de jogar planning poker em duas ocasiões diferentes: durante as primeiras interações, antes do projecto começar e quando novas stories forem identificadas durante uma iteração a decorrer.

Top 3 das Razões pelas Quais o Planning Poker é Óptimo

• Promove a colaboração ao envolver toda a equipa.
• Usa estimativas consensuais em vez de estimativas individuais.
• Através da discussão de cada user story, expõe problemas numa fase inicial do projecto.

Observar equipas de sucesso durante as suas sessões de poker planning demonstra, claramente, as três razões listadas. O Poker Planning é uma excelente ferramenta com muitos benefícios, mas existem outras formas de melhorar o ainda mais o processo.

Pequenos passos que a maior parte das pessoas se esquece, podem ser seguidos no sentido de melhorar o processo. Conhecer estas dicas vai possibilitar que um coach bem sucedido ou um membro de confiança da equipa ajude a sua equipa a melhorar. Quais são essas pepitas de sabedoria?

Aqueles que fazem o trabalho devem votar.

Muitas vezes, todos votam nas equipas agile, independentemente do seu papel no projecto. Apenas aqueles activamente envolvidos na story devem votar.

Os Gestores não votam.

Os gestores geralmente querem que o trabalho demore menos tempo, por isso votam sempre muito baixo. No entanto, têm mais experiência do que o típico membro de uma equipa.

Ao dar ao gestor o poder de veto sobre o consenso da equipa, numa circunstância específica, estes podem pedir à equipa que considere algo que possa AUMENTAR o tamanho.

Nunca permitam aos gestores dar low sizes ou convencer a equipa a diminuir o seu tamanho, porque a opinião deles carrega muito peso. As opiniões de um gestor vão agir como uma âncora e arrastar o tamanho para baixo, enquanto estes defendem vigorosamente a sua posição.

Quando há um empate na votação entre dois sizes que são consecutivos, escolha o tamanho maior e siga em frente.

Tamanhos consecutivos podem ser 5 e 8 se usar a sequência de Fibonacci para tamanhos (1, 2, 3, 5, 8, 13).  Uma divisão igual, normalmente, leva muito tempo a resolver, por isso, use o número mais alto.

Segundo a minha experiência, nunca ninguém concorda com um número a meio e normalmente escolhem o top size no final da discussão. Fazer uso destes factos é vantajoso e acelera todo o processo.

Parar discussões de implementação antes que cheguem longe de mais

As equipas tipicamente tornam-se muito técnicas nos detalhes, quando discutem uma user story. Embora isto seja aceitável até a um certo ponto, é algo que deve ser severamente limitado. As discussões não devem levar muito tempo.

As pessoas envolvidas no dimensionamento devem já ter uma ideia para a solução mais simples e plausível e escolher um size com base nesse cenário.

Enquanto muitos acreditam que mais discussão tornará o size mais preciso, na realidade isto não é verdade. É feito, em parte, para encorajar as equipas a dar o seu melhor palpite e seguir em frente. Contudo, existe uma falta de precisão distintiva, portanto a escala não é granular.

Usar um cartão “Preciso de uma pausa”.

As equipas a envolver-se demasiado nas suas sessões de poker planning, não se apercebendo quando certos membros da equipa precisam de uma pausa. Ter um cartão com “Preciso de uma Pausa” pode ser usado por alguém na equipa para chamar a atenção a toda gente para a necessidade de um intervalo.

Usar um temporizador para limitar a discussão. 

Usar um timer para limitar discussões é auto-explanatório. As discussões devem ser limitadas a não mais do que um minuto. 

Se não se consegue chegar a um consenso no final da terceira ronda, escolha o tamanho maior e siga em frente.   

Depois de duas rondas de discussão, mais tentativas não vão trazer grandes resultados e serão uma perda de tempo. Ao escolher o tamanho maior, a equipa tem folga para melhorar e não vai correr o perigo de ficar sem tempo.

O maior problema que as equipas tentam evitar é ficarem sem tempo, então este atalho deve resolver esta situação.

Fazer com que a pessoa a criar as user stories se encontre com o QA e Development leads antes de jogar Planning Poker

As user stories devem ter as respostas prontas às questões mais óbvias. Tendo as respostas prontas, a equipa pode concentrar-se no tamanho, não tendo de reunir informação.

Lembre-se da linha de base.

O que quer que seja que a equipa escolha como linha de base, precisa de ser consistente de iteração em iteração. Se um + ideal day é size one, então todas as iterações precisam de usar esse ponto de referência. Se uma user story é size one or three, isso precisa de se manter consistente entre interações. 

Por vezes, é útil abordar novamente a linha de base e discutir com a equipa o que acreditam que os sizes realmente sejam.

Falar em como fazer isto pode eventualmente conduzir a “size creeping”, quando a mentalidade da equipa muda a sua linha de base para um tamanho maior torna-se mais pequeno, ao longo do tempo.

Isto acontece geralmente quando a equipa não consegue cumprir com os seus compromissos durante várias iterações, mesmo que tudo pareça mais ou menos igual.

Divirta-se!

Jogar Planning Poker deve ser um exercício divertido e colaborativo. Muitas equipas tentam despachar aquilo durante uma hora ou duas e esquecem-se de desfrutar do trabalho. Há muitas formas engraçadas que podem ser introduzidas no processo.

Eu gosto de jogar poker a sério com os tamanhos, para ser mais divertido.

Para jogar, qualquer story, de qualquer tamanho, conta como uma carta de poker e, cada cinco stories, fazem um mão. Antes de começar, todos tentam escolher a melhor mão.

Tal encoraja a equipa a olhar para as user stories previamente, e aí tentar adivinhar que conjunto faz um straight ou four of a kind.  Os vencedores até podem ter direito a um pequeno prémio.

Planning Poker (Or Scrum Poker) para Equipas Distribuídas

“Como pode jogar Planning Poker com equipas que estão geograficamente distribuídas?” Existem muitas opções para conseguir isso. Estas são as mais comuns:

Opção-1: Janela de Chat (Tentei, mas deixa lacunas para pontos de selecção tendenciosos)

Mediums de comunicação como GoTo ou WebEx são usados quando as equipas estão geograficamente distantes. Uma vez que os requisitos estejam claros, o product owner pode dar o sinal para dar pontos, e cada membro pode usar a janela de chat para introduzir o seu número.

Opção-2: Webcam (Estou a usar esta no projecto actual – Não é muito divertida, mas funciona!)
Quando se usa vídeo conferência para se reunir com várias pessoas (o vídeo Google+, grátis e popular), uma pessoa lidera a reunião. Essa pessoa diz “1-2-3-Vamos”; depois de dizer “Vamos”, cada membro da equipa mostra a sua carta na webcam. 

Porque as ferramentas estavam a mostrar mútltiplas pessoas em vídeo em janelas de chat diferentes, os utilizadores em forma de mosaico, é fácil vê-los todos de uma vez. No entanto, numa nota engraçada, as pessoas tendem a mostrar só as cartas depois de ver as dos outros.

Para prevenir isso, peça a cada membro para segurar a sua carta com a parte de trás virada para a webcam. Assim que o anfitrião mandar, a equipa mostra a carta, todos têm de as virar simultaneamente.

Opção-3: Planning Poker.com (Bom. Mas não podem mudar as cartas)

Este website foi desenhado pela Mountain Goat Software, a mesma organização pioneira nas cartas de poker planning. É um site gratuito que permite ao moderador criar o projecto, adicionar stories e convidar pessoas por email para participar no processo.

Qualquer utilizador que clique neste link, vê a story e as cartas scrum standard.

O utilizador não precisa da autorização para clicar em cada Scrum ou postar as suas ideias sobre a complexidade da story. 

Opção-4: Google Docs
Esta ideia é simples: criar um spreadsheet no Google Docs e permitir que as pessoas partilhem os seus números

Opção-5: OneNote
A ideia é semelhante ao Google Docs, mas os documentos MS Office também oferecem sincronização ao vivo e plataformas. Enquanto o uso é limitado ao browser do desktop, mas as pessoas também podem postar as suas opiniões através dos seus smartphones. Utilizadores novos em OneNote vão beneficiar deste video para aprender o programa.

Opção-6: JIRA plugin
JIRA para gestão Scrum tem um plugin para integrar poker planning dentro de um JIRA UI. Mais detalhes estão disponíveis aqui.

Opção-7: Scrummy
Scrummy é um jogo de story point estimation para equipas scrum, desenvolvido pelo Chefs Web na Four Kitchens, para permitir uma participação mais fácil dos utilizadores remotos e para experimentar algumas novas tecnologias.