Guida Scrum · Eventi Scrum
Il ciclo dello Sprint in Scrum: durata, time-box e regole
Lo Sprint è il battito di Scrum: un evento a durata fissa di un mese o meno in cui le idee si trasformano in valore. Tutti gli altri eventi Scrum avvengono al suo interno, e un nuovo Sprint inizia non appena termina il precedente.
Punti chiave
- Gli Sprint hanno durata fissa, di un mese o meno, e si susseguono senza interruzioni.
- Non modificate l'ambito in modi che mettano a rischio lo Sprint Goal.
- Solo il Product Owner può annullare uno Sprint.
Regole dello Sprint
- Gli Sprint hanno durata fissa, di un mese o meno.
- Non vengono apportate modifiche che metterebbero a rischio lo Sprint Goal.
- La qualità non diminuisce.
- Il Product Backlog viene affinato secondo necessità.
- L'ambito può essere chiarito e rinegoziato con il Product Owner man mano che si impara di più.
Scegliere la durata dello Sprint
| Durata | Pro | Contro |
|---|---|---|
| 1 settimana | Feedback rapido; rischio basso | Maggiore carico dovuto agli eventi |
| 2 settimane | Equilibrato; il più comune | — |
| 3–4 settimane | Spazio per il lavoro complesso | Feedback più lento; più rischio per Sprint |
Gli Sprint più brevi generano più cicli di apprendimento e limitano il rischio a una quantità minore di tempo e costi.
Uno Sprint di due settimane in sintesi
| Giorno | Attività |
|---|---|
| Giorno 1 | Sprint Planning; inizia il lavoro |
| Giorni 1–10 | Daily Scrum ogni giorno; sviluppo; refinement |
| Giorno 10 | Sprint Review, poi Sprint Retrospective |
| Giorno successivo | Il nuovo Sprint inizia con lo Sprint Planning |
Annullare uno Sprint
Uno Sprint può essere annullato se lo Sprint Goal diventa obsoleto. Solo il Product Owner ha l'autorità di annullarlo. L'annullamento è raro e destabilizzante; di solito significa che il contesto di business è cambiato all'improvviso.
Consigli
- Mantenete stabile la durata dello Sprint per conoscere il ritmo del vostro team.
- Concludete gli Sprint a metà settimana per evitare i lunedì festivi e la stanchezza del venerdì.
- Proteggete lo Sprint da modifiche di ambito che minacciano l'obiettivo.
- Completate gli elementi invece di avviarne molti in parallelo.
Modelli gratuiti per questo argomento
Domande frequenti
Uno Sprint si può prolungare?
No. Se il lavoro non è completato, lo Sprint termina comunque nei tempi previsti e gli elementi non completati tornano nel Product Backlog.
Uno Sprint è la stessa cosa di un'iterazione?
Sì. Sprint è il termine di Scrum per un'iterazione. Vedi che cos'è uno sprint.
Quanto dovrebbe durare uno Sprint?
Un mese o meno. Molti team scelgono due settimane come equilibrio tra feedback rapido e carico degli eventi, poi mantengono stabile la durata.
La durata dello Sprint può cambiare?
Può, ma cambiarla spesso rende più difficili pianificazione e previsioni. Se la cambiate, fatelo in modo deliberato, ad esempio dopo una Retrospective, e mantenete costante la nuova durata.
Che cosa succede al lavoro non completato alla fine di uno Sprint?
Gli elementi del Product Backlog non completati tornano nel Product Backlog, dove il Product Owner li riordina. Non contano ai fini dell'Increment.
Si può aggiungere lavoro a uno Sprint in corso?
L'ambito può essere chiarito e rinegoziato con il Product Owner man mano che si impara di più, ma nessuna modifica dovrebbe mettere a rischio lo Sprint Goal. I Developer possono aggiungere attività allo Sprint Backlog man mano che il loro piano evolve.
Che cos'è uno Sprint Goal?
L'unico obiettivo dello Sprint, creato durante lo Sprint Planning. Dà ai Developer focus e flessibilità su quale lavoro preciso permette di raggiungerlo. Vedi Sprint Planning.
Chi può annullare uno Sprint?
Solo il Product Owner, e solo se lo Sprint Goal diventa obsoleto.
Gli Sprint di una settimana sono una buona idea?
Danno un feedback molto rapido e si adattano ai team con priorità che cambiano velocemente, ma gli eventi occupano una quota maggiore del tempo. Alcuni team con Sprint di una settimana passano a Kanban se la pianificazione risulta un onere.
Un team può avere uno Sprint senza un rilascio?
Sì. Ogni Sprint deve produrre almeno un Increment utilizzabile, ma rilasciarlo o meno è una decisione di business.
Che cos'è un hardening Sprint?
Uno Sprint dedicato a stabilizzare e testare il lavoro precedente prima del rilascio. Non fa parte di Scrum e spesso segnala che la Definition of Done è troppo debole.