Guia de Instruções do Scrumchkin — Nível Shu
Se você baixou ou comprou o Scrumchkin, talvez queira uma ajuda para tirar o máximo proveito das suas sessões. E embora exista um Guia de Instruções disponível, este post tem como objetivo ser um guia do tipo “leia enquanto joga” para você não precisar decorar tudo.
Definindo Papéis
Ok, precisamos de pelo menos 5 pessoas. No máximo 9. Além disso, precisamos de um ScrumMaster e um Product Owner.
Eu costumo pedir para todos apontarem o dedo para cima, contar até três e pedir que apontem para o ScrumMaster. E depois repetir o processo para definir o Product Owner. É divertido e evitamos perder tempo discutindo quem deveria assumir o papel.
Se houver pessoas que são ScrumMasters e Product Owners na vida real, sugiro que vivam novas experiências durante o jogo. Embora possa parecer ilógico à primeira vista, estar em um papel diferente ajuda a criar empatia entre os membros do time e promove uma compreensão mais ampla de todo o fluxo.
O ScrumMaster
O ScrumMaster pode executar as seguintes ações:
-
Comprar uma carta
-
Dar uma carta
-
Pegar uma carta de um membro do Dev Team e dar para outra pessoa
-
Remover um Impedimento
O Product Owner
O Product Owner pode executar as seguintes ações:
-
Descobrir uma nova Feature
-
Revelar o Business Value de uma Feature
-
Repriorizar o Backlog
-
Coletar feedback dos clientes
O Dev Team
Os membros do Dev Team podem executar as seguintes ações:
-
Comprar uma carta
-
Jogar uma carta
-
Estimar uma Feature
Descobrindo o Product Backlog inicial
O Product Backlog inicial consiste em 5 Features. As 2 primeiras estão estimadas e têm seu Business Value revelado. A terceira está apenas estimada.
É assim que um Product Backlog inicial se parece no Scrumchkin
Sugiro que você deixe o Product Owner revelar as cartas de feature e as cartas de Business Value enquanto um membro do Dev Team revela as cartas de Size, pois isso ajuda a inseri-los no mundo do jogo.
Depois de rodar algumas sessões, você pode querer experimentar alguns ajustes e variações.
Comprometendo-se com um Sprint Backlog
Uma Sprint tem 5 dias, e durante cada dia cada jogador pode executar duas ações. Existem cartas de Work numeradas como 1, 2 e 3 pontos de Work. E essas são todas as informações que eles terão para definir seu primeiro Sprint Backlog.
Ao final da Sprint, algumas cartas de feedback podem aparecer na mesa, de acordo com a seguinte fórmula:
Features Entregues menos Features Não Entregues
Não se preocupe, voltaremos às Cartas de Feature mais tarde.
Depois que o time decide o que está no Sprint Backlog, eles pegam suas cartas e as separam do Product Backlog.
Executando a Sprint
Não há ordem de turno.
Não há nada proibindo os jogadores de mostrar suas cartas uns aos outros.
Não há regra dizendo que precisam jogar duas ações seguidas.
Sabe por quê? Eles são um time auto-organizável. E como facilitador você vai ver esse processo acontecendo o tempo todo. Se você tiver um olhar atento, será capaz de fazer perguntas muito poderosas sobre o comportamento e as decisões deles.
Dúvidas sobre regras e decisões do time são ótimos iniciadores de conversa. E conversas são o ponto deste jogo, não tenha medo de interromper o jogo e começá-las.
Um dia acaba quando todos jogaram suas 2 ações. A Sprint acaba após 5 dias.
Se o time conseguiu entregar todas as features planejadas, você pode deixar o Product Owner ou o Dev Team gastar 2 ações para mover a primeira Feature do Product Backlog para o Sprint Backlog.
Cartas laranjas são instantâneas. Elas são jogadas no momento em que alguém as compra, e conta como uma única ação.
Bugs são irritantes. Além disso, URGENTE!
Bugs têm precedência sobre qualquer feature. Eles são bloqueadores e enquanto houver um bug na mesa, ninguém pode trabalhar em mais nada.
Technical Debt fica na mesa e afeta cada feature. O time deve decidir quando é o momento certo de atacar o Technical Debt para removê-lo da mesa.
Sick Day são na verdade Sick Weeks. Quem comprar esta carta não pode executar nenhuma ação até o final da Sprint atual.
Impediments são bloqueadores totais. Ninguém pode fazer nada até que o ScrumMaster o remova da mesa.
Mas ei, temos cartas boas também! Há duas cartas que também ficam na mesa e são cumulativas:
Bugs, como todo vilão famoso, têm sua própria kryptonita
Automated Tests torna cada correção de bug um pouco mais simples. Conforme essas cartas começam a ocupar espaço na mesa, o time começa a colher os benefícios da melhoria contínua.
Continuous Integration ajuda o time a eliminar Technical Debt. E conforme o sistema de Continuous Integration é melhorado, também melhora a facilidade de eliminar esse irritante Technical Debt.
Porém, essas cartas verdes não são de graça. Você precisa gastar uma ação para jogá-las. Faz sentido, não é? Como na vida real, Automated Tests e Continuous Integration não caem do céu (embora muitas vezes rodem na nuvem!).
Coletando Feedback
Após o final da Sprint, o facilitador faz um cálculo simples:
Features Entregues menos Features Não Entregues
Este é o número de Cartas de Feedback que estarão disponíveis para o Product Owner durante a próxima Sprint.
Também existem Cartas de Feedback boas, eu prometo
As cartas de feedback não são reveladas imediatamente; o Product Owner precisa gastar uma ação para coletar cada Carta de Feedback.
Cartas de Feedback ficam na mesa e afetam o Business Value de certas features. Elas provavelmente vão impactar a priorização do Product Backlog, o que consequentemente dará algum trabalho para o Product Owner.
Dica profissional: Como facilitador, você pode querer escolher qual Carta de Feedback vai dar ao Product Owner, já que algumas terão mais impacto e portanto iniciarão debates mais ricos.
Fim do Jogo
O Scrumchkin não termina. Todo mundo ganha se aprendeu algo enquanto se divertiu, e todo mundo perde se alguma amizade foi arruinada durante o processo.
A arte nunca está terminada, apenas abandonada.
Leonardo da Vinci
O facilitador deve sentir quando o jogo se torna mais mecânico e menos barulhento. É aí que ele termina. Na minha experiência, a maioria dos grupos atinge esse ponto em algum momento durante a 3ª Sprint, mas isso definitivamente não é uma regra.
É legal gastar 20 minutos fazendo um pequeno debriefing para que todos possam compartilhar seus insights e ideias de experimentos para fazer na vida real.
A propósito, você já experimentou o Debriefing Cube?
É isso! Vou escrever alguns posts de “nível Ra” nas próximas semanas.
Bom jogo!
Scrumchkin Instruction Guide — Shu Level foi originalmente publicado em Scrumchkin no Medium, onde as pessoas continuam a conversa destacando e respondendo a esta história.
