Guia Scrum | 25. Jogo de Estimativa de Equipe
Publicados: 2022-05-28O Team Estimation Game é uma técnica que facilita o Sprint Planning no Scrum. Como ele difere do Planning Poker? Por que algumas equipes de desenvolvimento a consideram uma ferramenta mais eficaz e outras não? Você encontrará tudo o que precisa saber sobre isso no artigo a seguir.
Jogo de Estimativa de Equipe - índice:
- Introdução
- Regras do jogo de estimativa de equipe
- Team Estimation Game versus Planning Poker
- Resumo
Introdução
O jogo de estimativa de equipe também é chamado de estimativa de raias. O último termo originou-se como observação espontânea de um jogo de cartas, pois a exibição de cartas se assemelhava às raias de uma piscina de água.
O Team Estimation Game está constantemente ganhando popularidade, pois permite que as equipes de desenvolvimento criem estimativas cerca de 3 vezes mais rápido do que usando o Planning Poker.
Escrevemos sobre essa técnica no artigo anterior. Hoje, vamos nos concentrar no jogo de estimativa de equipe.
Regras do jogo de estimativa de equipe
Prompts do jogo de estimativa de equipe:
- um baralho de cartas de histórias de usuário – preparado separadamente para cada jogo
- um baralho de cartas de Story Point – para uso repetido
Primeiro, empilhe os cartões de User Stories na ordem correspondente às entradas no Product Backlog. Para garantir que os mais urgentes sejam estimados primeiro.
Os cartões de pontuação geralmente contêm valores correspondentes à sequência de Fibonacci. Esta é uma sequência dos seguintes números: 0, 1, 3, 5, 8, 13, 20, 40 e 100. Você também pode rotulá-los com potências sucessivas do número 2, ou seja, 2, 4, 8, 16, 32 e assim por diante.
As fases do jogo Team Estimation:
- Introdução. Para jogar o Team Estimation Game, os membros do Time Scrum sentam-se ao redor de uma mesa. O Product Owner começa comprando a primeira carta do baralho da User Story e compartilhando seu conteúdo com todos. Em seguida, as cartas ficam na mesa. Em seguida, o Product Owner explica ao restante do Time Scrum que, a partir de agora, os jogadores avaliarão as User Stories como fáceis ou difíceis de implementar, colocando-as de acordo com a esquerda e a direita. Se algum deles apresentar algum grau de dificuldade, o jogador irá empilhar juntos, um em cima do outro na mesa. Agora, a pessoa sentada ao lado deles no sentido horário faz o próximo movimento.
- Um jogador compra uma carta do baralho da User Story. Após compartilhar seu conteúdo com todos, explica sua essência ao Product Owner. A pessoa que segura a carta então a coloca na mesa e seleciona um assento com base em sua opinião sobre a dificuldade desta História do Usuário. Em seguida, o jogador explica o raciocínio por trás da escolha a todos e o outro jogador fica livre para fazer perguntas sobre o raciocínio. Eles não podem questionar a decisão em si, mas os argumentos que justificam a decisão.
- Agora, os jogadores se revezam e têm duas opções para escolher:
- Repita o passo 2, ou
- Mova uma das cartas da mesa para a posição mais apropriada
- A fase final de colocação dos cartões de User Story acontece uma vez, ou muitas vezes, dependendo da prática do Time Scrum. Durante esta rodada, cada jogador tem mais uma oportunidade de mover uma das cartas da mesa para um local mais apropriado.
- Uma vez que os jogadores atribuem todas as cartas de Histórias de Usuários aos seus locais, representando níveis de dificuldade, a Equipe de Desenvolvimento segue para combinar o valor, atribuindo as cartas da pilha de Pontos de História. O primeiro cartão de história do usuário à esquerda recebe o cartão de pontos de história com o menor número de pontos pelo Product Owner. A regra para a colocação de cartas subsequentes é a mesma dos pontos 3 e 4. Isso completa a estimativa.
Se optarem pela segunda opção, também devem justificar o que os fez mudar de ideia. Os jogadores se revezam repetindo a etapa 3 até que todas as cartas do baralho da história do usuário sejam distribuídas e estimadas.
Team Estimation Game versus Planning Poker
O Team Estimation Game é considerado uma ferramenta de estimativa mais eficaz do que o Planning Poker. Devido às seguintes diferenças entre essas duas técnicas:
- Mesa de cartas. O jogo Team Estimation usa a conhecida “regra da mesa de cartas” dos jogos de cartas populares. Isso significa que, uma vez que você tenha colocado um cartão, você não pode recuperá-lo. Como a User Story é estimada por uma pessoa de cada vez, a flutuação entre as estimativas e o número de vezes que as posições mudam é significativamente menor, em comparação com o Planning Poker.
- Um cálculo preciso o suficiente. No Planning Poker, um consenso total deve ser alcançado para cada User Story. No Team Estimation Game, no entanto, apenas uma pessoa decide. Mesmo que sua estimativa esteja errada, outro Desenvolvedor provavelmente a colocará em correspondência com seu valor com mais precisão. Desta forma, garante-se a obtenção de estimativas suficientemente precisas e rápidas
- Esgotando o assunto da discussão. Discutir escolhas muitas vezes fica excessivamente longo ao jogar Planning Poker. O tempo deles é bastante reduzido durante um Jogo de Estimativa de Equipe porque eles se concentram em uma única decisão de um dos Desenvolvedores, e não na natureza de cada História de Usuário.
Uma desvantagem potencial do jogo de estimativa de equipe é uma sensação de injustiça. Se a equipe de desenvolvimento for maior que o número de histórias de usuário agendadas em um determinado Sprint, alguns desenvolvedores podem se sentir excluídos.
Jogo de estimativa de equipe - resumo
O Team Estimation Game tem uma opinião sobre a técnica de estimativa mais eficaz para a maioria dos Times Scrum. No entanto, é importante lembrar que é apenas uma ferramenta para estimar a dificuldade e o esforço das User Stories. E como qualquer ferramenta, devemos ajustá-la para atender às necessidades e capacidades dos membros da equipe.
Se você gosta do nosso conteúdo, junte-se à nossa comunidade de abelhas ocupadas no Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.
Guia do Scrum:
- Glossário de termos básicos, funções e noções
- O que é Scrum?
- Valores do Scrum
- Como implementar o Scrum na sua empresa?
- Time Scrum - o que é e como funciona?
- Quem é um Product Owner?
- Os erros mais comuns do Product Owner
- Quem é o Scrum Master?
- Características de um bom Scrum Master
- Os erros mais comuns do Scrum Master
- Quais estatísticas e métricas o Scrum Master deve acompanhar?
- Cooperação entre Product Owner e Scrum Master
- Equipe de Desenvolvimento em Scrum
- Os erros mais comuns dos desenvolvedores
- Artefatos do Scrum
- Escalando Scrum
- Backlog da Sprint
- O que é o Backlog do Produto?
- O que são histórias de usuários?
- Criando a melhor história de usuário com INVEST
- Os erros mais comuns da história do usuário
- Critérios de aceitação da história do usuário
- Estimativa e pontos de história no Scrum
- Poker de Planejamento
- Jogo de estimativa de equipe
- Definindo Incremento
- Eventos Scrum
- O que é Sprint no Scrum?
- Compromissos da Equipe Scrum - Objetivo do Produto, Objetivo do Sprint e Definição de Conclusão
- O que é um gráfico Burndown?
- Como criar e interpretar um gráfico de burndown?
- Vantagens e desvantagens do gráfico de burndown
- Quadros Kanban em Scrum e Scrumban
- Velocidade no Scrum - Velocidade da Equipe de Desenvolvimento
- Reunião diária
- Planejamento de Sprint
- Revisão da Sprint
- O que é uma Sprint Retrospective?
- Erros comuns durante uma Sprint Retrospective
- Nutrição do Backlog do Produto