Guia Scrum | 25. Jogo de Estimativa de Equipe

Publicados: 2022-05-28

O 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:

  1. Introdução
  2. Regras do jogo de estimativa de equipe
  3. Team Estimation Game versus Planning Poker
  4. 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.

Team Estimation Game

As fases do jogo Team Estimation:

  1. 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.
  2. 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.
  3. 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

    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.

  4. 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.
  5. 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.
Team Estimation Game

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.

Scrum Guide | 25. Team Estimation Game caroline becker avatar 1background

Autor: Caroline Becker

Como Gerente de Projetos, Caroline é especialista em encontrar novos métodos para projetar os melhores fluxos de trabalho e otimizar processos. Suas habilidades organizacionais e capacidade de trabalhar sob pressão de tempo fazem dela a melhor pessoa para transformar projetos complicados em realidade.

Guia do Scrum:

  1. Glossário de termos básicos, funções e noções
  2. O que é Scrum?
  3. Valores do Scrum
  4. Como implementar o Scrum na sua empresa?
  5. Time Scrum - o que é e como funciona?
  6. Quem é um Product Owner?
  7. Os erros mais comuns do Product Owner
  8. Quem é o Scrum Master?
  9. Características de um bom Scrum Master
  10. Os erros mais comuns do Scrum Master
  11. Quais estatísticas e métricas o Scrum Master deve acompanhar?
  12. Cooperação entre Product Owner e Scrum Master
  13. Equipe de Desenvolvimento em Scrum
  14. Os erros mais comuns dos desenvolvedores
  15. Artefatos do Scrum
  16. Escalando Scrum
  17. Backlog da Sprint
  18. O que é o Backlog do Produto?
  19. O que são histórias de usuários?
  20. Criando a melhor história de usuário com INVEST
  21. Os erros mais comuns da história do usuário
  22. Critérios de aceitação da história do usuário
  23. Estimativa e pontos de história no Scrum
  24. Poker de Planejamento
  25. Jogo de estimativa de equipe
  26. Definindo Incremento
  27. Eventos Scrum
  28. O que é Sprint no Scrum?
  29. Compromissos da Equipe Scrum - Objetivo do Produto, Objetivo do Sprint e Definição de Conclusão
  30. O que é um gráfico Burndown?
  31. Como criar e interpretar um gráfico de burndown?
  32. Vantagens e desvantagens do gráfico de burndown
  33. Quadros Kanban em Scrum e Scrumban
  34. Velocidade no Scrum - Velocidade da Equipe de Desenvolvimento
  35. Reunião diária
  36. Planejamento de Sprint
  37. Revisão da Sprint
  38. O que é uma Sprint Retrospective?
  39. Erros comuns durante uma Sprint Retrospective
  40. Nutrição do Backlog do Produto