La Sprint Review è un Evento Scrum che riassume il lavoro sul Prodotto completato durante la Sprint attuale. Si svolge nell’ultimo giorno della Sprint ed è aperta agli Stakeholder. Il suo scopo è valutare l’Incremento, ovvero presentare l’ultima versione del Prodotto. Una parte importante della Sprint Review è anche la discussione sui miglioramenti e aggiornamenti effettuati. E anche apportare le modifiche necessarie al Product Backlog, in modo che tutti gli Stakeholder possano vedere lo stato attuale del Prodotto.

Sprint Review – indice:

  1. Introduzione
  2. Il ruolo degli Stakeholder durante la Sprint Review
  3. Rilascio degli Incrementi
  4. Lavorare sul Product Backlog durante la Sprint Review
  5. Riepilogo

Introduzione

La Sprint Review e la Sprint Retrospective sono due Eventi di Riepilogo della Sprint. In questo articolo abbiamo scritto in modo più esteso sui ruoli che ciascun Evento Scrum svolge. Oggi, menzioneremo solo che forniscono un’opportunità per ancorare i tre pilastri dell’empirismo – trasparenza, ispezione e adattamento – riguardo al Prodotto e al lavoro del Team Scrum.

La Sprint Review è dedicata al Prodotto. E il suo scopo è ispezionare l’Incremento, ovvero i risultati del lavoro svolto nella Sprint appena conclusa. L’evento dura al massimo quattro ore. Tutti i membri del Team Scrum, così come gli Stakeholder, ovvero tutte le persone interessate ai progressi del Prodotto, vi partecipano.

Il ruolo degli Stakeholder durante la Sprint Review

Durante la Sprint Review, il Team Scrum presenta l’Incremento agli Stakeholder. In questo modo, riassume i compiti completati e risponde a domande specifiche:

  1. Chi ha svolto il compito?
  2. Cosa è stato fatto di specifico?
  3. Per quale scopo è stato fatto?
Sprint Review

Gli Stakeholder forniscono feedback ai membri del Team Scrum. Questo consente di adattarsi, ovvero di adeguare il modo di lavorare del Team Scrum alle esigenze e alla visione del Cliente. Questo viene fatto per massimizzare il valore commerciale del Prodotto. Il feedback fornito ad ogni Sprint Review è particolarmente importante quando si creano prodotti innovativi che devono essere adattati continuamente alle attività della concorrenza e alle esigenze del mercato.

Rilascio degli Incrementi

Non dovremmo considerare la Sprint Review come l’unico momento in cui il Team Scrum rilascia un Incremento al Cliente. Se alcune funzionalità del Prodotto soddisfano la Definizione di Fatto in anticipo, il Product Owner può decidere di rilasciarlo immediatamente.

È anche possibile che un elemento del Product Backlog su cui il Team Scrum ha lavorato in una determinata Sprint non sia stato completato e non soddisfi la Definizione di Fatto. Non può quindi essere rilasciato o persino presentato durante la Sprint Review.

Lavorare sul Product Backlog durante la Sprint Review

Aggiornare il Product Backlog è tanto parte della Sprint Review quanto presentare i risultati del lavoro agli Stakeholder. Di solito, l’aggiornamento del Backlog è dedicato all’ultima parte della riunione, quindi gli Stakeholder non devono partecipare.

Il Product Owner aggiorna il Product Backlog in base al feedback degli Stakeholder e alle lezioni apprese dal Team di Sviluppo. Questo è particolarmente cruciale se il feedback ottenuto ha un impatto sulla forma e sullo Scopo della prossima Sprint. Aggiornare il Backlog è quindi un passo essenziale per preparare la prossima Pianificazione della Sprint.

sprint review

Sprint Review – riepilogo

La Sprint Review è una riunione del Team Scrum con gli Stakeholder, durante la quale vengono presentati i risultati del lavoro sul Prodotto ottenuti nell’ultima Sprint. La sua parte chiave è una discussione con gli Stakeholder, durante la quale forniscono feedback sul Prodotto. Grazie a questa conversazione, è possibile adattare efficacemente e possibilmente correggere la direzione del lavoro sul Prodotto in base alle esigenze del mercato. Grazie alle discussioni con gli Stakeholder tenute alla fine di ogni Sprint, aumentano le possibilità di massimizzare il valore commerciale del Prodotto sviluppato dal Team Scrum.

Se ti piace il nostro contenuto, unisciti alla nostra comunità di api laboriose su Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Caroline Becker

Come Project Manager, Caroline è un'esperta nel trovare nuovi metodi per progettare i migliori flussi di lavoro e ottimizzare i processi. Le sue capacità organizzative e la sua abilità di lavorare sotto pressione temporale la rendono la persona migliore per trasformare progetti complicati in realtà.

View all posts →

Scrum Guide:

  1. Glossario dei termini, ruoli e nozioni di base
  2. Che cos'è Scrum?
  3. Valori Scrum
  4. Come implementare Scrum nella tua azienda?
  5. Team Scrum - cos'è e come funziona?
  6. Chi è un Product Owner?
  7. Gli errori più comuni del Product Owner
  8. Chi è lo Scrum Master?
  9. I più comuni errori del Scrum Master
  10. Quali statistiche e metriche dovrebbe monitorare lo Scrum Master?
  11. Team di sviluppo in Scrum
  12. I più comuni errori degli sviluppatori
  13. Artefatti Scrum
  14. Scaling Scrum
  15. Sprint Backlog
  16. Cos'è il Product Backlog?
  17. Cosa sono le User Stories?
  18. Creare la migliore User Story con INVEST
  19. I più comuni errori nelle User Story
  20. Criteri di accettazione della User Story
  21. Stima e Punti Storia in Scrum
  22. Planning Poker
  23. Gioco di Stima del Team
  24. Definizione di Incremento
  25. Eventi Scrum
  26. Che cos'è un grafico di burndown?
  27. Vantaggi e svantaggi del grafico di burndown
  28. Bacheche Kanban in Scrum e Scrumban
  29. Velocità nello Scrum - Velocità del Team di Sviluppo
  30. Daily Scrum Scrum giornaliero
  31. Pianificazione dello Sprint
  32. Revisione dello Sprint
  33. Che cos'è una Retrospettiva Sprint?
  34. Errori comuni durante una Retrospettiva di Sprint
  35. Nutrimento del Product Backlog
  36. Come creare e interpretare un grafico di burndown?