Guida Scrum | 28. Sprint in Scrum

Pubblicato: 2022-06-08

Diversi eventi minori costituiscono uno Sprint in Scrum. Gli Sprint, a loro volta, formano insieme un percorso volto allo sviluppo e al rilascio di un Prodotto. Ogni Sprint ha uno Sprint Goal specifico e uno Sprint Backlog gestito dal Team di Sviluppo.

Cos'è Sprint in Scrum – sommario:

  1. Sprint in Scrum – Introduzione
  2. Sprint nella struttura di Scrum
  3. Gli sprint ei tre pilastri dell'empirismo
  4. Trasparenza
  5. Ispezione
  6. Adattamento
  7. Quali modifiche apportare durante uno Sprint?
  8. Sprint in Scrum – Riepilogo

Sprint in Scrum – Introduzione

Lo Sprint è il più grande degli eventi in Scrum, di cui abbiamo parlato in questo articolo. Gli Sprint seguono un ciclo continuo dall'inizio alla fine del lavoro su un Prodotto. E ogni iterazione avvicina il team al raggiungimento dell'obiettivo del prodotto.

Ogni Sprint ha uno Sprint Goal specifico per garantire coerenza nel lavoro del Team di Sviluppo. Prende la forma di un obiettivo aziendale e risponde alla domanda "Perché?", "A quale fine?" , o "Perché?" .

Il flusso di lavoro di uno Sprint è documentato nello Sprint Backlog, che elenca il lavoro necessario per raggiungere lo Sprint Goal. La sua descrizione dettagliata può essere trovata qui.

sprint in scrum

Sprint nella struttura di Scrum

Ogni Sprint ha una struttura specifica e comprende i seguenti eventi:

  • Sprint Planning : inizia lo Sprint. Durante questo evento, lo Scrum Team seleziona dal Product Backlog il lavoro pianificato da svolgere nel nuovo Sprint
  • Daily Scrum : un evento quotidiano in cui gli sviluppatori pianificano le attività della giornata
  • Sprint Review : aperta agli stakeholder, che si tiene l'ultimo giorno di uno Sprint. Il suo scopo è sintetizzare lo Sprint in termini di avanzamento sul Prodotto
  • Sprint Retrospective – l'evento conclusivo di uno Sprint, dove lo Scrum Team discute le modalità di lavoro e le idee per il miglioramento

La ripetizione degli eventi Sprint promuove l'implementazione di buone pratiche organizzative. In altre parole, lo Scrum Team implementa le routine necessarie per una pianificazione efficace e, mentre lavora, richiama l'attenzione sui problemi che possono essere discussi in occasione di eventi appropriati.

Gli sprint ei tre pilastri dell'empirismo

Gli Sprint obbligano lo Scrum Team a scomporre il lavoro sul Prodotto in segmenti temporali uguali che non durano più di un mese. Questo quadro fisso rafforza i tre pilastri dell'empirismo:

  • trasparenza
  • ispezione
  • adattamento

Abbiamo parlato più dettagliatamente dei tre pilastri dell'empirismo e del loro ruolo in Scrum qui. Ma oggi vedremo come si applicano allo Sprint e alla sua struttura.

Sprints in Scrum and the three pillars of empiricism

Trasparenza

La suddivisione del lavoro in Sprint migliora la trasparenza poiché tutte le persone coinvolte possono ottenere le informazioni richieste sullo stato del lavoro sul Prodotto in ogni Sprint. Sprint Planning e Sprint Review, l'inizio e la fine di uno Sprint, combinati con un aggiornamento del Product Backlog, forniscono a tutte le parti interessate preziose informazioni sullo stato attuale del Prodotto.

Ispezione

Suddividendo il lavoro in Sprint è possibile monitorarne frequentemente l'andamento. Ciò promuove la costante identificazione dei problemi in due aree chiave. Questi sono:

  • problematiche legate al raggiungimento del Product Goal – all'inizio e alla fine dello Sprint, ovvero durante lo Sprint Planning e lo Sprint Review
  • ostacoli nel modo in cui lavora lo Scrum Team – durante i meeting giornalieri e alla fine di ogni Sprint, cioè durante il Daily Scrum e la Sprint Retrospective

Adattamento

L'adattamento è una parte molto importante del lavoro dello Scrum Team, in quanto permette di risolvere i problemi individuati durante l'ispezione. Durante ogni Sprint, Daily Scrum e Sprint Retrospective forniscono uno spazio sicuro per parlare di come migliorare lo Scrum Team. L'implementazione delle soluzioni proposte avviene immediatamente o all'inizio del prossimo Sprint.

Sprint Planning e Sprint Review creano uno spazio sicuro per la discussione sugli Obiettivi e sui metodi per raggiungerli. Un buon Scrum Team autogestito riesce a capire con successo cosa e come implementare per il prossimo Sprint.

Quali modifiche apportare durante uno Sprint?

Ogni Sprint lascia abbastanza spazio allo Scrum Team per migliorare e improvvisare il proprio modo di lavorare. Pertanto, identifica cosa cambiare durante uno Sprint. La Scrum Guide non fornisce un elenco di tali modifiche. Tuttavia, la nozione di empirismo fornisce linee guida da seguire e adattare al modo in cui lavora un particolare Scrum Team.

  1. Tutte le modifiche possono compromettere il raggiungimento dello Sprint Goal. Secondo la prima regola, durante uno Sprint non si può, ad esempio, ridurre il numero di cose da fare in quello Sprint, o modificarne significativamente le caratteristiche. Uno Sprint è strettamente legato allo Sprint Goal. Pertanto, quando cambia l'Obiettivo, dovremmo interrompere lo Sprint. Tuttavia, questo non accade quasi mai poiché l'unico motivo per cui uno Sprint fallisce è quando l'obiettivo diventa obsoleto. Tieni presente che la decisione di terminare uno Sprint spetta esclusivamente al Product Owner.
  2. La qualità del lavoro non può essere compromessa. Questa regola ha lo scopo di evitare che il lavoro svolto durante uno Sprint diventi un Incremento perché non soddisfa la Definizione di Completamento. Ridurre la qualità del lavoro può comportare il raggiungimento dell'Obiettivo Sprint, ma il modo in cui le singole attività vengono completate non soddisfa gli standard di qualità stabiliti dall'organizzazione o richiesti dalle parti interessate.
  3. Il Product Backlog può diventare dettagliato. Mentre si lavora su un Prodotto, la conoscenza a riguardo aumenta. Pertanto il dettaglio dei compiti da svolgere aumenta naturalmente. Pertanto, è un cambiamento accettabile e persino consigliabile durante uno Sprint per dettagliare il Product Backlog.
  4. L'ambito del lavoro può essere chiarito o rinegoziato. Questo cambiamento, come il precedente, comporta una comprensione crescente della natura del lavoro svolto. Il team di sviluppo può farlo in consultazione con il Product Owner. Tuttavia, la condizione fondamentale per la sua introduzione è l'assenza di contrasto con i principi 1. e 2.

Sprint in Scrum – Riepilogo

Sprint è l'evento Scrum ciclico che contiene tutti gli altri. Ha un obiettivo di sprint secondario separato dall'obiettivo di prodotto. E lo Sprint Backlog è diverso dal Product Backlog. La natura degli Sprint è ciclica. La durata fissa degli Sprint è favorevole al mantenimento di buone pratiche di flusso di lavoro e al mantenimento dei tre pilastri dell'empirismo. Durante uno Sprint, lo Scrum Team non può cambiare il suo Obiettivo. Può, tuttavia, perfezionare il Product Backlog e, man mano che le conoscenze crescono, perfezionare e negoziare l'ambito del lavoro.

Se ti piacciono i nostri contenuti, unisciti alla nostra indaffarata community di api su Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Autore: Natalia Jaros

Visualizza tutti i post

Guida alla mischia:

  1. Glossario di termini, ruoli e nozioni di base
  2. Cos'è Scrum?
  3. Valori di mischia
  4. Come implementare Scrum nella tua azienda?
  5. Scrum Team: cos'è e come funziona?
  6. Chi è un Product Owner?
  7. Gli errori più comuni del Product Owner
  8. Chi è lo Scrum Master?
  9. Caratteristiche di un buon Scrum Master
  10. Gli errori più comuni di Scrum Master
  11. Quali statistiche e metriche dovrebbe monitorare lo Scrum Master?
  12. Collaborazione tra Product Owner e Scrum Master
  13. Team di sviluppo in Scrum
  14. Gli errori più comuni degli sviluppatori
  15. Artefatti di Scrum
  16. Scalare Scrum
  17. Sprint arretrato
  18. Cos'è il Product Backlog?
  19. Cosa sono le User Story?
  20. Creare la migliore User Story con INVEST
  21. Gli errori di User Story più comuni
  22. Criteri di accettazione della User Story
  23. Stima e Punti Storia in Scrum
  24. Pianificazione del poker
  25. Gioco di stima della squadra
  26. Incremento di definizione
  27. Eventi Scrum
  28. Cos'è lo Sprint in Scrum?
  29. Impegni dello Scrum Team - Obiettivo del prodotto, Obiettivo dello Sprint e Definizione del completamento
  30. Che cos'è un diagramma di burndown?
  31. Come creare e interpretare un diagramma di burndown?
  32. Vantaggi e svantaggi del diagramma di burndown
  33. Tavole Kanban in Scrum e Scrumban
  34. Velocity in Scrum - Velocità del Team di Sviluppo
  35. Scrum quotidiano
  36. Pianificazione dello sprint
  37. Recensione Sprint
  38. Che cos'è una retrospettiva sprint?
  39. Errori comuni durante una Retrospettiva Sprint
  40. Consolidamento del Product Backlog