Sprint review: scopo, partecipanti e modalità di svolgimento

La revisione dello sprint è la cerimonia in cui il team mostra il prodotto funzionante alle parti interessate e raccoglie il feedback che definisce in modo nuovo ciò che verrà sviluppato in seguito. Si svolge al termine dello sprint, ha una durata prestabilita di circa due ore per uno sprint di due settimane e il suo risultato è un product backlog aggiornato. L’aspetto fondamentale da tenere presente è che si tratta di una sessione di lavoro, non di una presentazione. Il valore non risiede nella demo, bensì nelle decisioni che essa stimola.

A cosa serve la revisione dello sprint

Lo scopo della revisione è quello di rispondere a una domanda insieme alle persone a cui sta a cuore il risultato: alla luce di ciò che abbiamo appena realizzato, quale dovrebbe essere il nostro prossimo progetto?

Il team presenta l’incremento — il lavoro effettivamente completato, secondo la definizione di “completato”, non quello che è quasi pronto — e le parti interessate presenti in sala reagiscono. Pongono domande, sollevano obiezioni, notano ciò che nessuno aveva pensato di menzionare in fase di pianificazione. Tale reazione costituisce il risultato della riunione. Essa confluisce direttamente nel product backlog, che il product owner aggiorna immediatamente o poco dopo.

Sprint review e demo

Spesso si utilizzano i termini “sprint review” e “la demo” come se si trattasse della stessa riunione. Non è così: la demo è solo una parte della revisione.

Mostrare il software funzionante è importante: impone onestà (non è possibile presentare una funzionalità quasi completata) e offre a tutti lo stesso elemento concreto su cui basare le proprie reazioni. Tuttavia, se la demo è l’unica attività che si svolge — il team presenta, gli stakeholder applaudono, tutti se ne vanno — si è trattato di una comunicazione a senso unico. La revisione è la conversazione bidirezionale che la dimostrazione dovrebbe avviare. La dimostrazione è solo l’introduzione; il feedback e la ridefinizione delle priorità sono il vero obiettivo.

Chi vi partecipa e perché è rivolto verso l’esterno

La revisione dello sprint è l’unica cerimonia pensata per rivolgersi all’esterno. I partecipanti sono l’intero Scrum Team più le parti interessate invitate dal Product Owner: clienti, utenti, sponsor, personale di supporto e chiunque la cui reazione debba influenzare il prodotto.

Quella lista degli invitati è una scelta, non una formalità. Inviti persone in grado di fornire un feedback su cui valga la pena agire e selezioni i partecipanti con rigore: una sala piena di spettatori genera solo chiacchiere di cortesia; una sala con i tre clienti giusti produce invece un backlog riorganizzato. Questo approccio rivolto verso l’esterno è esattamente ciò che distingue la revisione dalla retrospettiva di sprint, che è riservata esclusivamente al team e privata per un motivo ben preciso.

Come organizzare un evento che valga davvero l’ora dedicata

Il formato è volutamente informale. Si tratti di una sessione di lavoro, non di uno spettacolo teatrale.

• Iniziate illustrando l’obiettivo dello sprint. Ricordate ai presenti quali erano gli obiettivi prefissati per questo sprint, in modo che l’incremento venga valutato in base alle intenzioni e non alle impressioni.
• Mostrate un prodotto funzionante, non delle diapositive. Presentate il prodotto reale confrontandolo con la definizione di “completato”. Tralasciate ciò che è “quasi completato”: ciò darebbe adito a discussioni su un lavoro che non è ancora terminato.
• Lasciate spazio alle reazioni. Il team dovrebbe dedicarsi più all’ascolto che alla presentazione. Domande, obiezioni e frasi del tipo «e se fosse possibile anche…» sono proprio il materiale che cercavate.
• Concludete aggiornando il backlog. Inserite i feedback nelle priorità finché sono ancora freschi. Questo è il risultato concreto della riunione.

La preparazione consiste soprattutto nel sapersi moderare: scegliere cosa mostrare, assicurarsi che funzioni davvero e resistere alla tentazione di creare un “deck”. Dieci minuti di una funzionalità funzionante valgono più di quaranta minuti di screenshot della stessa.

Revisione dello sprint vs retrospettiva di sprint

Le due cerimonie di chiusura vengono spesso confuse, pertanto prestate attenzione: la revisione esamina il prodotto insieme alle parti interessate; la retrospettiva esamina il processo del team, in privato. La revisione è rivolta verso l’esterno e si svolge per prima; la retrospettiva è rivolta verso l’interno e si svolge per seconda, in modo che il team possa integrare il feedback fresco sul prodotto nella propria riflessione.

Non si integrano bene: nessuno solleva la questione “i nostri test sono affrettati” di fronte al cliente, quindi fonderli insieme significa, di fatto, mettere a tacere la parte più onesta. Manteniamo il confronto completo, compreso chi partecipa a ciascuna di esse e il motivo per cui vanno tenute separate, in sprint review vs retrospettiva di sprint. Per quanto riguarda la collocazione di entrambe rispetto al resto delle riunioni, si veda le quattro cerimonie Scrum e le altre cerimonie di questa guida.

Domande frequenti

Qual è lo scopo di una revisione dello sprint?

Esaminare l’incremento del prodotto insieme alle parti interessate e adeguare le fasi successive. Il team mostra ciò che ha effettivamente portato a termine, le parti interessate reagiscono e tale reazione viene integrata nel product backlog. Il punto non sono gli applausi, bensì la correzione di rotta. Una revisione che non modifica in alcun modo il piano non è altro che una riunione di aggiornamento mascherata.

Chi partecipa alla revisione dello sprint?

L’intero Team Scrum, insieme alle parti interessate invitate dal Product Owner — clienti, utenti, sponsor e chiunque il cui feedback debba contribuire a plasmare il prodotto. È l’unica cerimonia che si rivolge deliberatamente all’esterno. Il Product Owner cura con attenzione l’elenco degli invitati affinché il feedback espresso in quella sede sia tale da giustificare un intervento concreto.

Quanto dovrebbe durare una revisione dello sprint?

Prevedete un tempo massimo di circa due ore a settimana per ogni sprint: fino a due ore per uno sprint di due settimane, fino a quattro per uno di un mese. Se i tempi si allungano, probabilmente state presentando delle diapositive invece di mostrare un prodotto funzionante, oppure state esaminando un lavoro che in realtà non è stato svolto.

Qual è la differenza tra una revisione dello sprint e una demo?

Una demo è una delle attività che compongono la revisione: consiste nel mostrare il software in funzione. La revisione dello sprint è invece il dibattito più ampio che la demo dà il via: le reazioni delle parti interessate, i cambiamenti nelle priorità, le modifiche al backlog. Se considerate la revisione solo come una demo, otterrete una presentazione unidirezionale che suscita annuimenti ma non porta a nessuna decisione.

Qual è la differenza tra una revisione dello sprint e una retrospettiva?

La revisione dello sprint analizza il prodotto insieme alle parti interessate, per stabilire cosa realizzare in seguito. La retrospettiva analizza il processo del team stesso, in privato, per capire come lavorare meglio nello sprint successivo. La revisione è rivolta verso l’esterno e viene prima; la retrospettiva è rivolta verso l’interno e viene dopo. Sono necessarie entrambe, ma non si combinano bene tra loro.