Planning Poker e Scrum Poker Um Guia Para Líderes

O Agile Software Development tem sido uma forma eficiente de desenvolver produtos digitais nos últimos anos, mas pensamos que não é suficiente para a sua empresa se tornar uma grande Empresa de Produtos Digitais. A ADAPT Methodology® é uma framework única de Desenvolvimento de Produto Digital para garantir o sucesso dos Líderes na Era Digital!

A sociedade mudou e os líderes precisam de apoio na forma como lideram e projetam as suas organizações de produtos digitais, razão pela qual a ADAPT Methodology® foi criada, mas agora vamos mergulhar profundamente no Planning Poker ou Scrum Poker.

[sc_pathway pathway_title="The Agile Transformation Roadmap" pathway_description="Do you want to do an Agile Transformation but you do not know where to start? This roadmap will help you! The Agile Transformation Roadmap was created based in several years of Agile transformations operated in Europe!" pathway_button_text="DOWNLOAD THE ROADMAP" pathway_button_url="https://adaptmethodology.com/agile-transformation-roadmap-en?utm_source=ADAPT_Methodology&utm_medium=CTA_Box&utm_content=Top_Box&utm_campaign=Planning_Poker" /]

Equipas ágeis de todo o mundo usam a técnica Planning Poker para estimar os seus produtos. O Planning Poker em Scrum reúne múltiplas opiniões de especialistas para a estimativa ágil de um produto.

O Planning Poker inclui todos: programadores, testers, engenheiros de bases de dados, analistas, designers de interação e todo o pessoal envolvido no produto. Estes membros da equipa representam todas as disciplinas num produto de software, que são mais adequados 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 Planning Poker 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 Planning Poker logo após o product backlog inicial estar construido. Essas sessões, que podem levar vários dias, servem para criar estimativas iniciais que são úteis no scope ou dimensionamento do produto.

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 Planning Poker 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 Planning Poker demonstra, claramente, as três razões listadas. O Planning Poker é 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, não 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 tamanho 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 Planning Poker, 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 Planning Poker. É 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 Planning Poker 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.

Em Resumo

O Planning Poker ajuda as equipas ágeis a estimar o tempo e o esforço necessários para completar cada iniciativa no atraso do seu produto. O nome desta técnica gamificada é Planing Poker porque os participantes usam cartas que assemelham-se a cartas de poker.

Uma das grandes coisas sobre o Planning Poker no Scrum é o facto de reunir múltiplas opiniões de especialistas para a estimativa que contribui para uma melhor estimativa.

Gostou deste artigo?

Permitimos que os líderes se tornem altamente valorizados e reconhecidos de forma a ter um impacto no Mundo, ajudando-os a projetar empresas de produtos digitais que irão prosperar e nutrir na Era Digital, fazemos isso aplicando a nossa própria ADAPT Methodology®.

Se quiser saber como podemos ajudá-lo visite a nossa página: Work With Us.

Se está interessado em saber se tem o que é preciso para construir uma Empresa de Produto Digital, veja o nosso Scorecard.

Se quiser aprender a construir uma Empresa de Produtos Digitais, dê uma olhada no nosso Digital Leadership Accelerator.