Lo Sprint Review
L’attività più ovvia in un Sprint Review Meeting è la dimostrazione delle funzionalità costruite nello Sprint precedente. Tuttavia, un buon Sprint Review è molto più di una semplice dimostrazione. Vediamo insieme un’agenda per un Review Meeting.
Creare il contesto giusto per il Review
Il Product Owner inizia lo Sprint Review Meeting dando il benvenuto a tutti i partecipanti. È più che sufficiente se dice qualcosa come: "Grazie a tutti per essere qui."
Se i presenti non si conoscono, il Product Owner può chiedere loro di presentarsi brevemente. All’inizio di una nuova iniziativa di sviluppo prodotto, un giro di presentazioni è generalmente una buona idea. Il Product Owner potrebbe sapere che Marco del Marketing è Marco del Marketing; tuttavia, i membri del team potrebbero non saperlo.
È anche una buona idea che tutti i partecipanti si presentino brevemente quando nuovi partecipanti si uniscono occasionalmente agli Sprint Review. Dopotutto, Marco del Marketing potrebbe partecipare solo agli Sprint Review dei due Sprint in cui il team ha lavorato su funzionalità legate al marketing.
Le presentazioni dovrebbero essere davvero brevi e concise. "Ciao, sono Luca e sono uno sviluppatore. Ho lavorato sulle funzionalità del carrello" è quasi troppo. "Ciao, sono Luca e sono uno sviluppatore" sarebbe sufficiente nella maggior parte dei casi. Tuttavia, una volta che un team raggiunge una certa dimensione, può essere piuttosto utile per gli stakeholder sentire brevemente su cosa ciascuno ha lavorato.
Dopo il benvenuto e le eventuali presentazioni necessarie all’inizio, il Product Owner può stabilire alcune regole aggiuntive o annunciare le aspettative per lo Sprint Review. Ad esempio, alcuni Product Owner ritengono importante sottolineare di mantenere sempre un tono amichevole durante lo Sprint Review. Quindi se a qualcuno non piace come una funzionalità è stata implementata, può certamente dirlo; tuttavia, non dovrebbe definire l’implementazione "stupida". Sì, naturalmente lo sappiamo tutti, ma a volte è necessario ricordarlo.
A seconda del numero di partecipanti e di molti altri fattori, il Product Owner può anche spiegare ai presenti che, sebbene il Review cerchi feedback sulle funzionalità costruite finora, questo non è il momento e il luogo per riprogettare completamente le funzionalità.
Una volta terminata l’introduzione e stabilite le regole per il Review, è il momento di passare al punto successivo dell’agenda.
Cosa verrà dimostrato in un Review – e cosa no?
A questo punto, molti team iniziano direttamente con la dimostrazione. Raccomando che il Product Owner dia prima una breve panoramica di ciò che verrà dimostrato e di ciò che non lo sarà.
Per evitare che il Product Owner legga semplicemente un elenco di elementi che i partecipanti non riescono a seguire, questo elenco dovrebbe essere mostrato su un monitor o proiettore visibile a tutti. Oppure stampate l’elenco in anticipo per chi potrebbe desiderarne una copia.
Personalmente, mi piace inviare queste informazioni come documento Word in un’email a tutti i potenziali partecipanti dello Sprint Review Meeting la sera prima della riunione. Questo dà alle persone la possibilità di vedere in anticipo cosa verrà dimostrato. Su questa base, ognuno può decidere autonomamente se vale la pena partecipare allo Sprint Review.
La seguente tabella mostra le informazioni che ritengo rilevanti per ciascun Product Backlog Item. Suggerirei di elencare gli elementi nell’ordine in cui vengono dimostrati. Tuttavia, questo può essere modificato al volo secondo necessità.
Il primo elemento della tabella è una descrizione del rispettivo elemento. Lì viene inserita una User Story o un’altra descrizione. Poi viene la dimensione degli elementi – solitamente in Story Point. Dopo c’è lo stato degli elementi. Principalmente si tratta di sapere se sono completati o meno. Ma qualsiasi altra informazione che sembra importante in tal senso può essere aggiunta. L’ultima colonna indica se l’elemento verrà dimostrato o meno.
Potresti chiederti perché dovrebbero esserci elementi nell’elenco che non verranno dimostrati. Ho incluso alcuni esempi nella tabella sopra. Ovviamente, l’elemento che è stato incluso nello Sprint ma poi eliminato non può essere dimostrato. Ho anche elencato una correzione di bug che riguarda solo l’aggiornamento di un carattere su una schermata – anche questo elemento non è destinato alla dimostrazione.
È possibile che uno o più partecipanti chiedano di vedere un elemento che in realtà non era previsto per la demo. Se ciò accade, sentiti libero di presentare quell’elemento insieme agli altri. Il punto non è evitare di mostrare certi elementi, ma rispettare il tempo delle persone non mostrando loro elementi su cui non serve feedback.
Nell’esempio della tabella, ho elencato un Product Backlog Item che è stato aggiunto durante lo Sprint. Penso sia utile poter vedere quali elementi erano programmati per lo Sprint dall’inizio e quali sono stati aggiunti durante lo Sprint. Se è più comune che gli elementi vengano aggiunti durante lo Sprint, puoi pensare di aggiungere una colonna alla tabella e annotare lì se gli elementi erano pianificati o aggiunti successivamente.
Inoltre, puoi aggiungere una colonna all’estrema destra indicando se gli elementi sono stati accettati dai partecipanti del Review Meeting, sono pronti per il Release o simili. Questo è particolarmente utile se queste decisioni sono parte ufficiale dello Sprint Review.
Cerca di non dedicare troppo tempo a questa parte dell’agenda. L’obiettivo qui non è ottenere feedback sugli elementi o parlare del perché un elemento pianificato è stato implementato solo parzialmente. Questo elenco serve semplicemente a presentare i contenuti della riunione. Dopo che il Product Owner ha presentato questo elenco, passiamo alla parte principale dello Sprint Review: la dimostrazione.
Nuove funzionalità
Questo è il cuore di ogni Sprint Review Meeting. Se stai già facendo Sprint Review, è anche possibile che questa sia l’unica parte dell’agenda che effettivamente svolgi.
In questa parte dello Sprint Review, passi in rassegna uno per uno gli elementi dell’elenco che hai precedentemente mostrato ai partecipanti. Ricorda che lo scopo di un Sprint Review Meeting è ottenere feedback.
Non c’è una regola fissa su chi debba fare la demo. In alcuni casi, sarà il Product Owner a farla. Io lo consiglierei sempre quando stakeholder particolarmente difficili partecipano al Review. In altri casi, i rispettivi membri del team dimostreranno gli elementi su cui hanno lavorato. Quasi ogni variazione è consentita. Basta sperimentare un po’ e scoprire cosa funziona meglio per il tuo team.
Gli elementi più importanti
Questo è il cuore di ogni Sprint Review Meeting. Se stai già facendo Sprint Review, è anche possibile che questa sia l’unica parte dell’agenda che effettivamente svolgi.
In questa parte dello Sprint Review, passi in rassegna uno per uno gli elementi dell’elenco che hai precedentemente mostrato ai partecipanti. Ricorda che lo scopo di un Sprint Review Meeting è ottenere feedback.
Non c’è una regola fissa su chi debba fare la demo. In alcuni casi, sarà il Product Owner a farla. Io lo consiglierei sempre quando stakeholder particolarmente difficili partecipano al Review. In altri casi, i rispettivi membri del team dimostreranno gli elementi su cui hanno lavorato. Quasi ogni variazione è consentita. Basta sperimentare un po’ e scoprire cosa funziona meglio per il tuo team.
I prossimi Product Backlog Item
L’ultimo punto dell’agenda dello Sprint Review dovrebbe essere una discussione sul prossimo lavoro nel Product Backlog. Poiché lo scopo dello Sprint Review è ottenere feedback sul lavoro dello Sprint corrente, spesso influenza il lavoro degli Sprint successivi.
Ad esempio, se gli stakeholder apprezzano molto l’aspetto delle nuove schermate, il Product Owner potrebbe voler adattare rapidamente altre aree del prodotto al nuovo design. Oppure gli stakeholder potrebbero non gradire il modo in cui le funzionalità sono state implementate. Allora il prossimo Sprint può essere utilizzato per risolvere questi problemi anziché passare ai prossimi elementi (come sarebbe avvenuto senza uno Sprint Review).
Il Product Owner inizia la discussione presentando i prossimi potenziali elementi dal Product Backlog. Potrebbe dire qualcosa come: "Sullo schermo vedete dieci elementi che avevo pianificato per il prossimo Sprint. Tuttavia, vorrei ancora aggiungere l’elemento XY, emerso oggi. Probabilmente lo inserirò come elemento n. 3."
Il Product Owner chiede poi ai partecipanti la loro opinione su questo elenco. Tuttavia, a mio parere, il Product Owner non dovrebbe prioritizzare durante lo Sprint Review sulla base di questi commenti. Ci sono diversi motivi. Il Product Owner potrebbe aver bisogno di tempo per riflettere su quanto è stato detto. O forse vuole ottenere valutazioni dal team sulle modifiche richieste nel Review, ecc. Quindi il Product Owner raccoglie le opinioni nello Sprint Review e prende le decisioni finali con calma dopo la riunione.
La fine di ogni Review
Concludi semplicemente la riunione ringraziando tutti per la partecipazione. Inoltre, considera di ringraziare il team nel suo complesso per il lavoro svolto nell’ultimo Sprint, o occasionalmente uno o due membri del team che si sono distinti particolarmente. Poi ricorda a tutti quando e dove si terrà il prossimo Sprint Review Meeting.
Dopo lo Sprint Review
Anche se non fa direttamente parte dell’agenda dello Sprint Review, bisogna assicurarsi che tutti i nuovi Product Backlog Item vengano trasferiti anche nel tool del team o scritti su un Post-It e attaccati alla Scrum Board.
