Guida alle istruzioni di Scrumchkin: Livello Shu

Guida alle Istruzioni di Scrumchkin — Livello Shu

Se hai scaricato o comprato Scrumchkin, potresti volere un aiuto per ottenere il massimo dalle tue sessioni. E anche se c’è una Guida alle Istruzioni disponibile, questo post vuole essere una guida del tipo “leggi mentre giochi” così non devi memorizzare tutto.

Definire i Ruoli

Ok, abbiamo bisogno di almeno 5 persone. Massimo 9. Inoltre, ci servono uno ScrumMaster e un Product Owner.

Spesso chiedo a tutti di puntare le dita verso l’alto, contare fino a tre e chiedere loro di indicare lo ScrumMaster. E poi ripetere il processo per definire il Product Owner. È divertente e evitiamo di perdere tempo a discutere chi dovrebbe assumere il ruolo.

Se ci sono persone che sono veri ScrumMaster e Product Owner, suggerisco loro di vivere nuove esperienze durante il gioco. Anche se può sembrare illogico all’inizio, essere in un ruolo diverso aiuta a creare empatia tra i membri del team e favorisce una comprensione più ampia dell’intero flusso.

Lo ScrumMaster

Lo ScrumMaster può eseguire le seguenti azioni:

• Pescare una carta

• Dare una carta

• Prendere una carta da un membro del Dev Team e darla a qualcun altro

• Rimuovere un Impedimento

Il Product Owner

Il Product Owner può eseguire le seguenti azioni:

• Scoprire una nuova Feature

• Rivelare il Business Value di una Feature

• Riordinare il Backlog

• Raccogliere feedback dai clienti

Il Dev Team

I membri del Dev Team possono eseguire le seguenti azioni:

• Pescare una carta

• Giocare una carta

• Stimare una Feature

Scoprire il Product Backlog iniziale

Il Product Backlog iniziale consiste in 5 Feature. Le prime 2 sono sia stimate che hanno il loro Business Value scoperto. La terza è solo stimata.

Ecco come appare un Product Backlog iniziale in Scrumchkin

Ti suggerisco di lasciare che il Product Owner riveli le carte delle feature e le carte del Business Value mentre un membro del Dev Team rivela le carte Size, dato che questo aiuta a inserirli nel mondo del gioco.

Dopo aver fatto alcune sessioni, potresti voler provare alcune modifiche e variazioni.

Impegnarsi per uno Sprint Backlog

Uno Sprint dura 5 giorni, e durante ogni giorno ogni giocatore può eseguire due azioni. Ci sono carte Work numerate come 1, 2 e 3 punti Work. E queste sono tutte le informazioni che avranno per definire il loro primo Sprint Backlog.

Alla fine dello Sprint, alcune carte feedback potrebbero apparire sul tavolo, secondo la seguente formula:

Feature Consegnate meno Feature Non Consegnate

Non preoccuparti, torneremo alle Carte Feature più tardi.

Dopo che il team decide cosa c’è nel loro Sprint Backlog, prendono le carte e le separano dal Product Backlog.

Eseguire lo Sprint

Non c’è un ordine di turno.

Non c’è nulla che vieti ai giocatori di mostrare le loro carte agli altri.

Non c’è una regola che dice di giocare due azioni di fila.

Sai perché? Sono un team auto-organizzato. E come facilitatore vedrai questo processo accadere continuamente. Se hai un occhio attento, sarai in grado di fare domande molto potenti sul loro comportamento e sulle loro decisioni.

I dubbi sulle regole e sulle decisioni del team sono ottimi spunti di conversazione. E le conversazioni sono il punto di questo gioco, non aver paura di interrompere il gioco e iniziarle.

Un giorno finisce quando tutti hanno giocato le loro 2 azioni. Lo Sprint finisce dopo 5 giorni.

Se il team è riuscito a consegnare tutte le feature pianificate, puoi lasciare che il Product Owner o il Dev Team spendano 2 azioni per spostare la prima Feature del Product Backlog nello Sprint Backlog.

Le carte arancioni sono istantanee. Vengono giocate nel momento in cui qualcuno le pesca, e conta come una singola azione.

I Bug sono fastidiosi. Inoltre, URGENTE!

I Bug hanno la precedenza su qualsiasi feature. Sono bloccanti e mentre c’è un bug sul tavolo, nessuno può lavorare su nient’altro.

Il Technical Debt resta sul tavolo e influenza ogni feature. Il team deve decidere quando è il momento giusto per affrontare il Technical Debt e rimuoverlo dal tavolo.

I Sick Day sono in realtà Sick Week. Chiunque peschi questa carta non può eseguire alcuna azione fino alla fine dello Sprint corrente.

Gli Impedimenti sono bloccanti totali. Nessuno può fare nulla finché lo ScrumMaster non lo rimuove dal tavolo.

Ma ehi, abbiamo anche carte buone! Ci sono due carte che restano sul tavolo e sono cumulative:

I Bug, come ogni famoso cattivo, hanno la loro kryptonite

Gli Automated Tests rendono ogni correzione di bug un po’ più semplice. Man mano che queste carte iniziano a occupare spazio sul tavolo, il team inizia a raccogliere i benefici del miglioramento continuo.

La Continuous Integration aiuta il team a eliminare il Technical Debt. E man mano che il sistema di Continuous Integration migliora, migliora anche la facilità di eliminare questo fastidioso Technical Debt.

Tuttavia, queste carte verdi non sono gratuite. Devi spendere un’azione per giocarle. Ha senso, no? Come nella vita reale, Automated Tests e Continuous Integration non cadono dal cielo (anche se spesso girano nel cloud!).

Raccogliere Feedback

Dopo la fine dello Sprint, il facilitatore fa un semplice calcolo:

Feature Consegnate meno Feature Non Consegnate

Questo è il numero di Carte Feedback che saranno disponibili per il Product Owner durante il prossimo Sprint.

Ci sono anche Carte Feedback buone, lo prometto

Le carte feedback non vengono rivelate subito; il Product Owner deve spendere un’azione per raccogliere ogni Carta Feedback.

Le Carte Feedback restano sul tavolo e influenzano il Business Value di certe feature. Probabilmente avranno un impatto sulla prioritizzazione del Product Backlog, il che di conseguenza darà del lavoro al Product Owner.

Consiglio pro: Come facilitatore, potresti voler scegliere quale Carta Feedback dare al Product Owner, dato che alcune avranno più impatto e quindi inizieranno dibattiti più ricchi.

Fine del Gioco

Scrumchkin non finisce. Tutti vincono se hanno imparato qualcosa divertendosi, e tutti perdono se qualche amicizia è stata rovinata durante il processo.

L’arte non è mai finita, solo abbandonata.

Leonardo da Vinci

Il facilitatore deve percepire quando il gioco diventa più meccanico e meno rumoroso. È lì che finisce. Nella mia esperienza, la maggior parte dei gruppi raggiunge quel punto da qualche parte durante il 3° Sprint, ma questa non è assolutamente una regola.

È bello spendere 20 minuti facendo un piccolo debriefing così tutti possono condividere i loro insight e idee di esperimenti da fare nella vita reale.

A proposito, hai provato il Debriefing Cube?

Questo è tutto! Scriverò alcuni post di “livello Ra” nelle prossime settimane.

Buon gioco!

Scrumchkin Instruction Guide — Shu Level è stato originariamente pubblicato in Scrumchkin su Medium, dove le persone continuano la conversazione evidenziando e rispondendo a questa storia.