Revisione dello sprint: 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 ridefinisce 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 un’esibizione. 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.

Revisione dello sprint vs demo

Spesso si utilizzano i termini “sprint review” e “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 trasmissione 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. Una dimostrazione eseguita per ottenere applausi senza che ne derivino decisioni concrete è teatro agile: una cerimonia organizzata per il pubblico anziché per il risultato.

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 Team Scrum, oltre alle 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 produce solo rumore di sottofondo; una sala con i tre clienti giusti produce invece un backlog riordinato. Questo approccio aperto è esattamente ciò che distingue la revisione dalla retrospettiva di sprint, che è riservata esclusivamente al team e si svolge in privato 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 che questo sprint si proponeva di raggiungere, 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 state cercando.
• Concludete aggiornando il backlog. Inserite i feedback nelle priorità finché sono ancora freschi. Questo è il risultato concreto della riunione.

La preparazione consiste soprattutto nel dare prova di moderazione: scegliere cosa mostrare, assicurarsi che funzioni davvero e resistere alla tentazione di creare un “deck”. Dieci minuti di funzionamento di una funzionalità 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 tra loro. Nessuno solleva la questione «i nostri test sono affrettati» di fronte al cliente, quindi fonderli insieme significa di fatto sopprimere silenziosamente la parte più onesta. Manteniamo il confronto completo, compreso chi partecipa a ciascuna e il motivo per cui le teniamo separate, nella revisione dello sprint rispetto alla retrospettiva di sprint. Per quanto riguarda la collocazione di entrambe rispetto alle altre riunioni, si vedano le quattro cerimonie Scrum e le altre cerimonie descritte in questa guida.

Domande frequenti

Qual è lo scopo di una revisione dello sprint?

Esaminare l’incremento di prodotto con le 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 della 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, oltre alle parti interessate invitate dal Product Owner: clienti, utenti, sponsor e chiunque il cui feedback debba contribuire a plasmare il prodotto. Si tratta dell’unica cerimonia che si rivolge deliberatamente all’esterno. Il Product Owner cura con attenzione l’elenco degli invitati affinché il feedback espresso durante l’incontro 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 si superano questi limiti, 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 funzionante. La revisione dello sprint è invece il dibattito più ampio che la demo avvia: le reazioni delle parti interessate, i cambiamenti nelle priorità, le modifiche al backlog. Se considerate la revisione solo come una demo, otterrete una presentazione a senso unico che suscita annuimenti ma non porta a nessuna decisione.

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

La revisione dello sprint prevede l’analisi del prodotto insieme alle parti interessate, al fine di decidere quali funzionalità sviluppare successivamente. La retrospettiva prevede invece l’analisi interna del processo del team, in forma riservata, per migliorare il lavoro nello sprint successivo. La revisione è rivolta all’esterno e ha la precedenza; la retrospettiva è rivolta all’interno e viene dopo. Entrambe sono necessarie, ma non si combinano bene tra loro.