Lo Sprint

Gli Sprint sono eventi di lunghezza fissa di un mese o meno per creare una cadenza di consegna e feedback coerente per lo Scrum Team. Più breve è la lunghezza dello Sprint, più veloce è il ciclo di feedback. Per esempio, Scrum Inc. lavora in Sprint di una settimana.

Lo Sprint è un contenitore di tutti gli altri eventi. Un nuovo Sprint inizia immediatamente dopo la conclusione dello sprint precedente, e ogni Sprint inizia tipicamente con la Pianificazione dello Sprint e finisce con la Revisione dello Sprint & Retrospettiva dello Sprint. Durante ogni giorno dello Sprint, c’è un breve evento chiamato Daily Scrum che serve a mantenere il team allineato e a scoprire gli impedimenti che il team incontra per fare progressi sullo Sprint Backlog. Tutto il lavoro e gli eventi necessari per raggiungere lo Sprint Goal, inclusi la Pianificazione dello Sprint, gli Scrum giornalieri, la Revisione dello Sprint e la Retrospettiva dello Sprint, avvengono all’interno degli Sprint.

Il ciclo regolare dello Sprint serve a:

• Focalizzare la consegna sullo Sprint Goal. Ogni Sprint il team dovrebbe sviluppare un incremento potenzialmente spedibile di software, un’iterazione utilizzabile di un prodotto hardware, o infine: un valore distinto per il cliente.
• Dare al team un feedback regolare e di alta qualità sul valore consegnato. Il team può quindi ispezionare e adattare sia il suo processo che il suo prodotto sulla base di input reali e azionabili del cliente.
• Misurare l’output del team su un periodo coerente e ricorrente. Questa misurazione dell’output è chiamata Velocity del Team. Il Team può usare la Velocity per prevedere la propria capacità di consegnare il lavoro nel tempo, e creare piani di sprint realistici basati su dati storici.

Gli Sprint permettono la prevedibilità assicurando l’ispezione e l’adattamento dei progressi verso il Product Goal almeno ogni mese di calendario. Sprint più brevi possono generare più cicli di apprendimento e limitare il rischio di costi e sforzi ad un periodo di tempo più piccolo. Quando l’orizzonte di uno Sprint è troppo lungo, lo Sprint Goal può diventare non valido, la complessità può aumentare e il rischio può aumentare. Ogni sprint può essere considerato un progetto breve e può essere cancellato se lo Sprint Goal diventa obsoleto. Solo il Product Owner ha l’autorità di cancellare lo sprint.