Guida Scrum · Eventi Scrum
Sprint Review: obiettivo, agenda e checklist
La Sprint Review ispeziona il risultato dello Sprint e stabilisce i futuri adattamenti. Lo Scrum Team presenta i risultati agli stakeholder chiave e insieme discutono l'avanzamento verso il Product Goal.
Punti chiave
- La Sprint Review ispeziona l'Increment e adatta il Product Backlog.
- È una sessione di lavoro con gli stakeholder, non una presentazione di slide.
- Mostrate solo il lavoro che soddisfa la Definition of Done.
Scopo principale
La Sprint Review è una sessione di lavoro, non una presentazione. Il suo obiettivo è ispezionare ciò che è stato fatto e adattare il Product Backlog in base al feedback e ai cambiamenti del contesto. La Guida Scrum mette in guardia dal limitarla a una presentazione.
Chi partecipa e quanto dura
- Lo Scrum Team e gli stakeholder chiave invitati dal Product Owner.
- Time-box di quattro ore per uno Sprint di un mese; di solito più breve per Sprint più brevi.
Agenda di esempio
- Benvenuto e Sprint Goal: che cosa il team si era proposto di ottenere.
- Che cosa è stato fatto, che cosa no, e perché.
- Dimostrazione dell'Increment, idealmente con prova diretta da parte degli stakeholder.
- Feedback e domande.
- Cambiamenti nel mercato, nel budget, nella tempistica o nelle capacità.
- Discussione del Product Backlog: che cosa fare dopo.
- Revisione della previsione di rilascio o dell'avanzamento verso il Product Goal.
Checklist di preparazione
- Invitate gli stakeholder giusti con largo anticipo.
- Confermate quali elementi soddisfano la Definition of Done; mostrate solo quelli.
- Preparate un ambiente realistico per la dimostrazione.
- Tenete pronti il Product Backlog ed eventuali grafici di previsione.
- Decidete chi mostrerà ciascun elemento.
- Preparate le domande a cui volete che gli stakeholder rispondano.
Errori da evitare
- Mostrare lavoro non completato.
- Presentazioni di slide invece di software o risultati funzionanti.
- Nessuno stakeholder reale presente.
- Raccogliere feedback senza mai aggiornare il backlog.
- Trattarla come un cancello di approvazione; i rilasci possono avvenire in qualsiasi momento.
Modelli gratuiti per questo argomento
Domande frequenti
Qual è la differenza tra una Sprint Review e una demo?
Una demo mostra il lavoro; una Sprint Review discute anche il feedback e adatta il Product Backlog.
Chi conduce la Sprint Review?
Lo Scrum Team; il Product Owner guida spesso la discussione sul backlog.
Quanto dura una Sprint Review?
Un massimo di quattro ore per uno Sprint di un mese. Gli Sprint più brevi hanno di solito Review più brevi.
Chi partecipa alla Sprint Review?
Lo Scrum Team e gli stakeholder chiave, di solito invitati dal Product Owner.
Qual è l'output di una Sprint Review?
Feedback sull'Increment e un Product Backlog adattato, eventualmente con previsioni aggiornate verso il Product Goal.
La Sprint Review è un cancello per il rilascio?
No. La Guida Scrum afferma che la Sprint Review non dovrebbe mai essere considerata un cancello per il rilascio di valore. Gli Increment possono essere rilasciati non appena sono pronti.
Il lavoro non completato va mostrato alla Sprint Review?
Il lavoro che non soddisfa la Definition of Done non fa parte dell'Increment e non dovrebbe essere presentato come completato. I team possono menzionarlo quando discutono che cosa è stato completato e che cosa no.
Come ci si prepara a una Sprint Review?
Invitate gli stakeholder giusti, confermate quali elementi soddisfano la Definition of Done, preparate un ambiente di demo realistico e tenete pronti il Product Backlog e le previsioni.
Che cosa fare se gli stakeholder non partecipano alla Sprint Review?
Scoprite perché, adeguate orario o formato e mostrate loro come il loro feedback cambia le priorità. Senza stakeholder, l'evento perde gran parte del suo valore.
La Sprint Review si può svolgere da remoto?
Sì. Condividete una demo dal vivo o lasciate che gli stakeholder provino l'Increment in prima persona, e usate una board condivisa per raccogliere feedback e modifiche al backlog.
Chi presenta durante la Sprint Review?
Di solito i Developer mostrano il lavoro che hanno realizzato e il Product Owner guida la conversazione sul Product Backlog e sui passi successivi.