Revisione dello sprint: finalità, 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 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 interessate al 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 rispondono. 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 usano 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 è fondamentale: impone onestà (non è possibile presentare una funzionalità quasi completata) e offre a tutti lo stesso elemento concreto su cui reagire. Tuttavia, se la dimostrazione è 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 vi siano decisioni concrete alle spalle è 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 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 produce solo rumore di fondo; 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 al solo team e si svolge in forma 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 con l’obiettivo dello sprint. Ricordate ai presenti quali erano gli obiettivi che questo sprint si prefiggeva 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ò suscita discussioni su un lavoro che non è ancora terminato.
• Lasciate spazio alle reazioni. Il team dovrebbe dedicarsi maggiormente all’ascolto piuttosto che alla presentazione. Domande, obiezioni e frasi del tipo «e se fosse possibile anche…» costituiscono proprio il materiale che siete venuti a cercare.
• Concludete aggiornando il backlog. Inserite i feedback nelle priorità finché sono ancora freschi. Questo è il risultato concreto che la riunione produce.

La preparazione consiste soprattutto nel dar 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. Nessuno solleva la questione “i nostri test sono affrettati” davanti al cliente, quindi fonderli insieme significa, di fatto, mettere a tacere la parte più onesta. Manteniamo il confronto completo, compreso chi partecipa a ciascuna 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 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 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 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 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 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 in seguito. La retrospettiva prevede invece l’analisi interna del processo del team stesso, in forma riservata, per migliorare il lavoro nello sprint successivo. La revisione è rivolta all’esterno e ha la priorità; la retrospettiva è rivolta all’interno e viene dopo. Sono necessarie entrambe, ma non si combinano bene tra loro.