Sprint Review meeting

Lo Sprint Review meeting ha lo scopo di dimostrare al Product Owner l’incremento di prodotto su cui il team ha lavorato durante l’iterazione appena conclusa. È pratica comune servirsi di una demo delle funzionalità introdotte, anche se non è obbligatorio, mentre è sconsigliato utilizzare slide PowerPoint.

Ogni iterazione è pianificata in sede di Sprint Planning. Se non ricordi come, puoi dare un’occhiata a questo articolo.

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

Come si svolge lo Sprint Review meeting

Il meeting comincia con una dimostrazione di ciò che è stato fatto durante lo Sprint appena terminato. Si parte con la prima user story e si procede con quelle successive, fino a quando non si esauriscono i requisiti presenti nello Sprint Backlog.

Se per esempio la prima user story è:

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

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

sprint review meeting

Verifica delle user story

Se la validazione del form era parte degli acceptance criteria, il team deve dimostrare che anche quella parte è stata implementata. Se tutto funziona, il Product Owner dichiara la user story “completata”. Gli Story Point relativi alla user story vengono quindi considerati per il calcolo della Velocity.

Se invece la validazione del form non funziona, o altre parti non sono state ultimate come da acceptance criteria o Definition of Done, la user story viene dichiarata “non completata” e viene spostata nuovamente nel Product Backlog, pronta a essere analizzata e ri-estimata durante la successiva sessione di Sprint Refinement. Gli Story Point, in questo caso, non vengono inclusi nel calcolo della Velocity.

Facciamo finta che il Product Owner non sia soddisfatto pienamente perché manca il bottone per il recupero password. Se questa funzionalità era parte degli acceptance criteria, allora la user story non è stata completata. Se invece questa funzionalità non era presente, il team può creare una nuova user story da aggiungere al Product Backlog.

Feedback sul lavoro svolto

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

Facciamo finta che il form di login dell’esempio precedente non abbia il flag per ricordare la password; una funzione che magari uno degli stakeholder, particolarmente smemorato, trova di fondamentale importanza.

Tutte le persone presenti al Review meeting hanno la facoltà di scrivere nuove user story e aggiungerle al Product Backlog, in modo che il Product Owner possa definirne le priorità e pianificarle per iterazioni successive. Nel caso di questo esempio, verrà creata una nuova user story per il flag “ricorda la password”.

Lo Sprint Review meeting, oltre a essere un importante strumento di verifica, incoraggia il feedback e lo scambio di idee. È importante sottolineare come tutto ciò che non è stato considerato in fase iniziale può tranquillamente essere aggiunto per iterazioni future, ma non va in alcun modo a invalidare l’incremento appena rilasciato.

A meno che ovviamente non si manifestino problemi o errori gravi che possono causare instabilità al prodotto.