La Sprint Review è l’evento in cui lo Scrum Team e gli stakeholder (usualmente invitati dal Product Owner) si incontrano per ispezionare l’Incremento e adattare il Product Backlog. Questa frequenza di ispezione e adattamento del lavoro svolto è molto importante per capire se la direzione intrapresa è corretta e insieme decidere cosa fare in seguito.
Si tratta di un evento informale, che non ha bisogno di preparazione, perché verrà ispezionato un Incremento Done e quindi, per definizione, corretto e senza anomalie, pronto per essere messo in produzione se il Product Owner lo decide.
Un possibile risultato di questo evento potrebbe essere (vedi la Guida Scrum):
- Presentazione dello Sprint Goal (definito in Sprint Planning) dal Product Owner
- Descrizione degli elementi del Product Backlog implementati dalla definizione di Done e non Done, relativo allo Sprint Goal, dal Product Owner
- I Developers condividono i contenuti dell’Incremento con le scelte tecniche effettuate per le soluzioni implementate
- Rendere l’Incremento disponibile agli Stakeholders per ottenere feedback
- Adattare il Product Backlog con nuove idee, un ordine diverso, l’eliminazione di alcuni elementi, ecc.
- Revisione del Product Backlog e condivisione delle date estimate di consegna in funzione dei progressi compiuti fino ad oggi (dati empirici).
LA SPRINT REVIEW NON È
- Una demo: ad esempio solo un video, con le nuove funzionalità, mostrato agli Stakeholders.
- La lettura di un Power Point: teorico, possibilmente con screenshot, che spiega cosa è stato fatto.
- Una presentazione del lavoro svolto dai Developers al Product Owner, allo Scrum Master o ad un manager.
nella SPRINT REVIEW Non abbiamo nulla da mostrare
C’è sempre qualcosa da ispezionare in Sprint Review, se la Scrum Team si trova in una situazione in cui non c’è nulla da mostrare agli Stakeholders, si deve avere il coraggio di mantenere l’evento e spiegare in modo trasparente gli ostacoli (impediments) che hanno impedito la creazione dell’Incremento Done alla fine dello Sprint.
Le disfunzioni riscontrate sul terreno, che portano a questo tipo di situazione, possono essere:
- Elementi del Product Backlog troppo grandi da sviluppare durante lo Sprint;
- Lo Scrum Team non ha tutte le abilità per creare un Incremento Done;
- Lo Scrum Team, che lavora su diversi progetti/prodotti in multitasking, senza potersi concentrare sulla creazione dell’Incremento
- Un prodotto esistente che viene tagliato in strati tecnici
- L’assenza di uno Sprint Goal
- …
Qualunque cosa accada, lo Scrum Team si auto-organizzarsi per poter, in Sprint Review, portare del valore agli stakeholders. L’interesse deriva dall’essere riusciti a creare una variazione del valore del prodotto rispetto all’ultima volta. Questo può essere difficile all’inizio, in alcune situazioni. L’annullamento della Sprint Review non aiuterà a migliorare, al contrario, avrà un effetto negativo sulla trasparenza del lavoro e impedirà allo Scrum Team di ricevere feedback preziosi.
Scarica e stampa (in A4 o A3) il poster relativo a questo articolo, può essere utile per te in ufficio, i codici QR consentono di approfondire gli argomenti proposti!
Questo articolo fa parte di una serie di dodici pubblicazioni, ognuna delle quali spiega le basi di Scrum, secondo lo Scrum Guide. Potrebbe essere utile per te come presentazione alla direzione o per chiunque sia curioso di approfondire l’argomento.
Tradotto dal francese da Denise Monreale, grazie!
