Sprint Review meeting: molto più di una Demo

Lo Sprint Review meeting ha lo scopo di ispezionare il risultato dello Sprint e determinare eventuali aggiustamenti futuri. Non è un meeting con finalità di reporting ed è un evento informale, molto simile a una discussione, che coinvolge Scrum Team e Stakeholder.

Questo evento ha un timebox di al massimo 4 ore per uno Sprint di un mese. In un tipico Sprint di 2 settimane, richiede generalmente un paio di ore.

Per facilitare la discussione, è pratica comune servirsi di una demo delle funzionalità introdotte, anche se questo aspetto non è obbligatorio. È invece sconsigliato utilizzare slide PowerPoint.

Lo Sprint Review chiude di fatto un’iterazione, che ha inizio ed è pianificata in sede di Sprint Planning. Se non ricordi come, puoi dare un’occhiata a questo articolo.

Come si svolge lo Sprint Review meeting

Questo meeting, che vede la partecipazione di tutto il team Scrum, è aperto anche agli stakeholder interni, ai clienti, e a eventuali utenti finali. Ciò nonostante, come accennato in apertura, lo Sprint review deve essere mantenuto il più informale possibile.

Non esiste un format specifico e lo Sprint Review dovrebbe somigliare a una conversazione tra Scrum Team e stakeholder, più che a un tradizionale meeting di chiusura progetto o di “status report”. 

Il meeting in genere comincia con un’introduzione, spesso condotta dal Product Owner, su ciò che è stato fatto durante lo Sprint appena terminato, su come ciò aggiunga valore per l’utente finale e su come il risultato contribuisca al raggiungimento del Product Goal.

La demo non è obbligatoria, ma è indubbiamente un ottimo metodo per visualizzare il lavoro svolto. Durante la demo si può decidere di passare in rassegna le user story e i Backlog Item presenti nello Sprint Backlog. L’importante però è che questa attività non sia meramente finalizzata a dimostrare il completamento dei task, ma si svolga nel contesto di una discussione sullo Sprint Goal.

Ti ricordo che lo Sprint Goal, identificato in sede di Sprint Planning, è l’obiettivo dell’iterazione. Il Product Goal è invece l’obiettivo a lungo termine per il prodotto, è definito dal Product Owner e fa parte del Product Backlog.

Il risultato della discussione può portare il team ad adattare i propri piani per il futuro, e se necessario aggiungere nuove iniziative al Product Backlog.

Dimostrazione e verifica delle user story

Prendiamo per esempio la seguente user story:

As a user I want to login so that I can access the members area

Il team dimostrerà che riempiendo i campi del form di login e inviando il modulo, l’utente è in grado di autenticarsi e accedere all’area privata.

Se la validazione del form era parte degli acceptance criteria, il team dimostrerà che anche quella parte è stata implementata. Se tutto funziona come previsto, il Product Owner può “accettare” la User Story come parte dell’incremento potenzialmente rilasciabile. Gli Story Point relativi alla user story completata vengono quindi considerati per il calcolo della Velocity.

Se invece la validazione del form non funziona, o alcune parti non sono state ultimate come da acceptance criteria e Definition of Done, la user story viene dichiarata “non completata”. Gli Story Point, in questo caso, non vengono inclusi nel calcolo della Velocity e tutto il lavoro non completato viene spostato nuovamente nel Product Backlog, pronto per essere analizzato e ri-estimato, ed eventualmente incluso nella prossima iterazione.

Ovviamente, l’ideale sarebbe non attendere lo Sprint Review per trovare errori o per valutare se una funzionalità si comporti come previsto. Product Owner e team dovrebbero comunicare costantemente durante lo Sprint, e la validazione dovrebbe avvenire non appena la User Story è stata completata. In questo modo, il team ha l’opportunità di adattare o correggere il lavoro svolto prima della conclusione dell’iterazione. Il Review meeting è una piattaforma di ispezione e adattamento. Non per “validare” l’esito di uno Sprint.

Facciamo però finta che durante il meeting il Product Owner o gli Stakeholder non siano soddisfatti pienamente perché manca il bottone per il recupero password. In questo caso, qualora non fosse già presente, il team può creare una nuova user story da aggiungere al Product Backlog.

Feedback sul lavoro svolto

È normale che in fase di discussione o di demo saltino all’occhio alcuni aspetti e funzionalità che non sono state considerate in fase iniziale. Oppure che la funzionalità, così come implementata, non soddisfi pienamente gli stakeholder o gli utenti finali.

Tutte le persone presenti al Review meeting hanno la facoltà di suggerire nuove user story da aggiungere al Product Backlog, in modo che il Product Owner possa valutarne la proposta di valore, definirne le priorità e pianificarle per iterazioni successive. Ma nessun partecipante esterno allo Scrum Team ha l’autorità di dichiarare l’incremento “incompleto” o bloccare un eventuale rilascio in produzione.

La decisione di rilasciare in produzione le funzionalità completate, e quindi in linea con la Definition of Done, spetta esclusivamente al Product Owner, indipendentemente dal “titolo” o dalla posizione lavorativa dei presenti. Le parti mancanti o non finalizzate possono tranquillamente essere aggiunte al Product Backlog per iterazioni future

Lo Sprint Review meeting, dicevamo, è un importante strumento di ispezione e incoraggia il feedback e lo scambio di idee. Gli stakeholder hanno quindi l’occasione di influenzare la direzione del prodotto e per discutere nuove idee, ma non possono in alcun modo imporre le proprie decisioni.

Considerazioni finali su Sprint Review

L’esempio che abbiamo visto in precedenza, ovvero passare in rassegna ciascuna User Story all’interno dello Sprint Backlog, potrebbe essere una buona idea. Ma come già detto, attenzione a non far diventare questo meeting come il momento in cui il Product Owner vede per la prima volta il lavoro ultimato e “accetta” le User Story.

In una situazione ideale o in team maturi, il dialogo tra Product Owner e sviluppatori è continuo, e gli sviluppatori dovrebbero già sapere, prima di questo meeting, che cosa può essere considerato completato e cosa invece no.

Un altro aspetto importante da tenere in considerazione è che in fase di Sprint Review dovrebbe essere discusso o dimostrato anche il lavoro non svolto o parzialmente svolto. E non solo per una questione di trasparenza e apertura. Lo scopo dello Sprint Review è infatti quello di ottenere un feedback che può essere utilizzato per lo sviluppo di future iterazioni, e in quest’ottica discutere il lavoro che non si ha avuto modo di terminare potrebbe tornare utile.

Infine non dimenticare che un buon Sprint Review meeting dovrebbe sempre discutere i progressi del team in una prospettiva più ampia, e non limitata ai soli Backlog Item presenti nello Sprint Backlog. Partire dal perché, e includere un po’ di contesto prima di buttarsi nei tecnicismi, potrebbe essere un ottimo approccio per includere nella conversazione anche quegli Stakeholder che non hanno (o non vogliono avere) una visione completa e dettagliata sulla parte tecnica di implementazione.

È FINALMENTE DISPONIBILE IL VIDEOCORSO DI AGILE WAY!

videocorso agile way su scrum e sulle metodologie agili

CORSO APPROFONDITO SU SCRUM E SULLE METODOLOGIE AGILI

Aggiornato all’ultima versione della guida ufficiale di Scrum!

Più di 3,5 ore di video lezioni su Scrum, ideale per prepararsi a un esame di certificazione PSM I e per comprendere i valori, i principi e le pratiche dei metodi Agili. In questo corso imparerai:

  • Origine, nascita e significato delle metodologie Agili
  • Differenze tra Scrum e i modelli tradizionali
  • Tutte le componenti del framework Scrum, i valori, le pratiche e le metriche
  • Come gestire al meglio un progetto e un prodotto con Scrum
  • Come mantenere un’attenzione continua al valore generato e al cliente
  • Simulatore di esame di certificazione (80 domande)
  • Tanto altro…

* Offerta limitata nel tempo

Subscribe
Notificami
guest
0 Commenti
Inline Feedbacks
View all comments