Il media che reinventa l'impresa
Il media che reinventa l'impresa
Sprint review: probabilmente starete pensando allo sprint esponenziale di Bolt nei 100 m o alla Pellegrini, quando a una vasca dalla fine, supera tutti e vince con il suo sprint eccezionale? E invece no. Niente di tutto ciò.
Se la vostra azienda ha adottato la metodologia di project management Scrum Agile, avrete almeno una volta sentito parlare o assistito a una sprint review.
Se, invece, è la prima volta che incrociate questo termine, Appvizer ha preparato un articolo per voi in cui troverete la definizione della sprint review e il suo svolgimento.
Per chi è già più familiare con una sprint review e magari ha già partecipato a più di una, vi sveleremo anche qualche segreto per una sprint review di successo sia in qualità di partecipante che di organizzatore di questo meeting.
La sprint review è un evento Scrum che ha luogo alla fine dello sprint, appena prima della retrospettiva. Lo scopo della revisione è di valutare le ultime caratteristiche e di considerare il piano per il prodotto in futuro.
Uno dei vantaggi chiave della metodologia Scrum è che dà maggiore visibilità, controllo e gestione del rischio rispetto al tradizionale sviluppo waterfall ("a cascata"). La sprint review è il momento in cui tutto ciò avviene, permettendo all'intero team Scrum di riunirsi con tutte le parti interessate e lavorare insieme per decidere il modo migliore di procedere.
Non è un evento formale, è molto più simile a una discussione, che coinvolge lo Scrum Team e gli stakeholders.
Di solito ha una durata di massimo 4 ore per uno sprint di un mese e per uno sprint di 2 settimane di un paio di ore.
Per rendere più interessante la discussione, il product owner prepara, per gli stakeholders, una demo delle funzionalità introdotte sul prodotto o servizio. Non è consigliato, invece, utilizzare slide PowerPoint.
La sprint review ha lo scopo di ottenere un feedback dagli stakeholder sulle user stories fatte durante lo sprint. La definizione delle user stories include il deployment in produzione, il test di accettazione, e qualsiasi altra cosa necessaria per rilasciare la user story all'utente finale.
©ancaonuta.medium.comNon c'è un'agenda prescritta per la sprint review, ma di solito segue un ordine stabilito:
Più nel dettaglio:
1. Cosa è stato fatto?
Il product owner presenta un riassunto delle nuove caratteristiche sviluppate e consegnate.
2. Dimostrazione.
Il development team (il team di sviluppo) mostra cosa hanno costruito e come funziona.
3. Analisi delle condizioni di mercato.
Il product owner fornisce un aggiornamento su qualsiasi cambiamento rilevante al mercato in cui il loro prodotto compete.
4.Piano di rilascio e previsione.
Il product owner presenta il piano attuale e le date di consegna previste.
5. Modifiche proposte.
L'intero gruppo collabora per discutere i potenziali cambiamenti al piano, che possono includere:
Se svolto in modo corretto, lo sprint review sposta l'organizzazione lavorativa da una mentalità di gestione del progetto tradizionale a una mentalità di ottimizzazione del prodotto e della sua product value (valore aggiunto).
È probabile che la previsione di release cambi rispetto alla proiezione originale. È ancora più probabile che l'ambito e i requisiti originali non siano la migliore versione possibile del prodotto che potrebbe essere concepito.
Una sprint review efficace permette di rivalutare tutte le decisioni prese sul prodotto, in modo che in ogni momento il piano rifletta il miglior corso d'azione possibile.
Uno stakeholder può essere chiunque sia interessato agli argomenti funzionali trattati durante la dimostrazione del lavoro svolto dello sprint. Possono essere manager, utenti, colleghi, futuri clienti. Spetta al product owner di identificarli e invitarli alla Sprint Review.
Il product owner presenta il lavoro fatto durante la sprint review e lo dimostra agli stakeholder. Seconda la metodologia Scrum, chiunque potrebbe fare la demo, ma é consigliabile che sia il product owner a farlo. Un product owner che dimostra il lavoro fatto è un product owner consapevole di ciò che il team ha realizzato, sicuro della qualità del lavoro e a suo agio nel condividerlo con tutti i partecipanti.
Le Sprint Review sono aperte a tutti. Tutti sono invitati a dare un feedback, ma spetta di solito ai product owner scegliere i partecipanti.
Il tempo è poco, e mentre si fornisce un feedback, le discussioni possono andare avanti a lungo. Raccomandiamo di usare i post-it per scrivere i feedback o di usare un semplice documento word per tenere traccia dei feedback se tutti i partecipanti sono nella stessa sala riunioni. Se gli utenti hanno familiarità con il software di project management che usate, possono aggiungere il loro feedback direttamente al product backlog.
Se usate un documento online, come, potete aggiungere una pagina lì con il feedback di ogni Sprint Reviews, o creare una pagina in una nota dedicata al feedback delle Sprint Reviews.
Vi consigliamo di firmare il feedback in modo che il product owner possa contattarvi per ulteriori dettagli.
Lo Scrum Master facilita la Sprint Review, e la demo è fatta dal Product Owner, principalmente.
Non necessariamente. Per quanto la struttura e l'organizzazione siano importanti, è inutile sovraccaricare il team di lavoro amministrativo non necessario. La parola d'ordine è essere minimalista. Meglio non usare presentazioni ma i soliti software di project management.
Ecco una piccola panoramica:
Sprint Goal: molti software presentano un campo per inserire lo sprint goal. Si trova di solito sotto il nome dello sprint o direttamente uno spazio dedicato all'obiettivo dello sprint.
Dimostrare il lavoro fatto: prendere ogni user story, spike, e requisiti non funzionali nell'ordine di importanza e mostrarli direttamente nel product space.
Richiedere un feedback: nell'apertura della Sprint Review, lo Scrum Master fornisce delle istruzioni chiare su come comunicare i feedback.
Discutere il lavoro non fatto, come base per la discussione. Nell'area di discussione di ogni elemento, ci dovrebbero essere i dettagli discussi per seguire meglio la user story di ogni elemento dello sprint backlog.
Identificare i rischi e le sottocategorie. E caldamente consigliato l'uso di qualsiasi software di project management per registrare i rischi e le sottocategorie. hanno un elemento di lavoro di rischio. Assicurarsi di collegarlo precisamente agli elementi del product backlog che hanno un impatto sulla stessa user story o feature.
Rivedere gli obiettivi del progetto. I team di scrum definiscono gli obiettivi durante il Program Increment Planning Meeting. Dopo ogni Sprint Review, ogni team deve valutare i propri progressi rispetto agli obiettivi pianificati. Durante la revisione degli obiettivi, i business owner assegnano la business value che pensano di aver guadagnato con il lavoro fatto durante lo sprint. Questo valore è soggettivo e deve riflettere il valore che il prodotto ha acquisito durante la sprint review.
Uno sneak peek - aprire il product backlog e mostrare cosa gli stakeholder potrebbero aspettarsi a grandi linee dal prossimo sprint. In un ambiente altamente organizzato, i team avranno una buona idea di ciò che verrà nella prossima iterazione.
La sprint review non è una sessione di product testing. Il test deve essere parte del processo delle user story e svolto prima di presentare il prodotto alla sprint review. E soprattutto come abbiamo ripetuto più volte non è una demo per il product owner.
