Che cos'è uno Sprint in Agile? Durata, eventi ed esempi

Che cos'è uno sprint in Agile?

A sprint è un periodo di durata fissa, di un mese o meno, in cui un team Agile lavora verso un unico Sprint Goal e produce almeno un Increment utilizzabile del prodotto. Gli sprint si susseguono senza interruzioni, e ogni attività di pianificazione, coordinamento, revisione e miglioramento del prodotto avviene al loro interno.

Il termine deriva da Scrum, il framework Agile più diffuso. La Scrum Guide (edizione 2020, ancora la versione ufficiale attuale) descrive gli sprint come il battito cardiaco di Scrum, dove le idee si trasformano in valore. Altri metodi Agile usano il termine iterazione per lo stesso concetto, e molti team che non seguono Scrum alla lettera dicono comunque "sprint".

Qualunque sia il nome, uno sprint ha cinque caratteristiche distintive:

• Durata fissa. La durata è stabilita in anticipo e resta la stessa da uno sprint all'altro, così il team impara il proprio ritmo.
• Un unico obiettivo. Ogni sprint ha uno Sprint Goal: un unico obiettivo che spiega perché vale la pena svolgere lo sprint.
• Un risultato utilizzabile. Alla fine, il team produce un Increment che soddisfa la Definition of Done, anche se non è ancora stato rilasciato.
• Uno dopo l'altro. Un nuovo sprint inizia subito dopo la fine del precedente.
• Tutto al suo interno. Pianificazione, coordinamento quotidiano, refinement, review e retrospettiva avvengono tutti all'interno dello sprint, non prima né dopo.

Sono i cicli brevi e fissi a rendere Agile empirico: ogni poche settimane il team e i suoi stakeholder esaminano un output reale e funzionante e decidono cosa fare dopo.

Sprint vs iterazione vs Scrum

Questi termini vengono spesso confusi. La tabella mostra come sono collegati.

In breve, uno sprint è un tipo di iterazione e Scrum è il framework che dà le regole allo sprint. L'idea alla base di entrambi è lo sviluppo iterativo e incrementale: costruire il prodotto a piccole porzioni e migliorarlo a ogni ciclo.

Quanto dura uno sprint?

La Scrum Guide stabilisce una sola regola: uno sprint dura un mese o meno. Entro questo limite, decide il team. In pratica la maggior parte dei team fa sprint da una a quattro settimane, e due settimane è di gran lunga la scelta più comune perché bilancia un feedback rapido con l'onere di pianificazione e revisione.

Come scegliere la durata dello sprint

Scegli la durata più breve in cui il team può consegnare qualcosa di significativo e Done. Poi considera:

• Quanto velocemente cambiano le cose. Più il mercato o i requisiti sono volatili, più lo sprint dovrebbe essere breve.
• Quanto può attendere il feedback. Se gli stakeholder devono vedere l'avanzamento ogni settimana, uno sprint di quattro settimane è troppo lungo.
• Dimensione degli elementi. Se la maggior parte degli elementi del backlog richiede più di qualche giorno, suddividili prima di allungare lo sprint.
• Vincoli di rilascio e di test. Integrazione, controlli di conformità o tempi di consegna dell'hardware possono rendere poco pratici gli sprint molto brevi.
• Allineamento. I team che lavorano sullo stesso prodotto di solito condividono la durata e la data di inizio dello sprint.

Cambiare la durata dello sprint

Mantieni stabile la durata per almeno diversi sprint, in modo che la tua velocity e le previsioni abbiano un significato. Cambiala deliberatamente in una retrospettiva, non a metà sprint, e non allungare mai un singolo sprint perché il lavoro non è finito. Per le regole specifiche di Scrum, consulta la nostra guida al ciclo dello Sprint in Scrum.

Gli elementi costitutivi di uno sprint

Tre elementi danno forma a uno sprint: un obiettivo, un piano e un risultato.

Sprint Goal

Lo Sprint Goal è l'unico obiettivo dello sprint. Viene creato durante lo Sprint Planning ed è l'impegno assunto dai Developer. Un buon Sprint Goal descrive un risultato, non un elenco di ticket, lasciando al team lo spazio per adattare il lavoro di dettaglio man mano che impara.

• Debole: "Completare i ticket 412, 415, 419 e 420."
• Migliore: "Consentire ai clienti abituali di completare l'acquisto in un solo passaggio, per verificare se riduce i carrelli abbandonati."
• Esempio non software: "Lanciare la landing page della campagna di primavera e le prime due email, così il team commerciale può iniziare i contatti lunedì."

Sprint Backlog

Il Sprint Backlog è composto dallo Sprint Goal, dagli elementi del Product Backlog selezionati per lo sprint e dal piano dei Developer per consegnarli. Appartiene ai Developer, che lo aggiornano per tutto lo sprint affinché tutti possano vedere il lavoro rimanente.

Increment e Definition of Done

Un Increment è un passo verso il Product Goal che è utilizzabile e soddisfa la Definition of Done. Il lavoro che non soddisfa la Definition of Done non fa parte dell'Increment, per quanto vicino sia. In uno sprint si possono creare più Increment, che possono essere rilasciati in qualsiasi momento; la Sprint Review non è un gate di rilascio.

Gli eventi all'interno di uno sprint

Lo sprint è un contenitore per altri quattro eventi. I time-box indicati di seguito sono i massimi previsti dalla Scrum Guide per uno sprint di un mese; per sprint più brevi gli eventi sono di solito più corti.

Sprint Planning apre lo sprint. Il Product Owner spiega quali obiettivi contano di più, i Developer selezionano gli elementi che ritengono di poter completare e insieme il team definisce lo Sprint Goal. I Developer pianificano poi come svolgere il lavoro, spesso suddividendo gli elementi in attività di un giorno o meno.

Il Daily Scrum è un controllo di 15 minuti per i Developer. Non è un report di stato per un manager. La domanda che conta è: siamo sulla buona strada per lo Sprint Goal e, se no, cosa cambiamo oggi?

La Sprint Review è una sessione di lavoro, non una presentazione di slide. Il team mostra ciò che è Done, gli stakeholder danno feedback e il gruppo discute cosa fare dopo, aggiornando il Product Backlog.

La Sprint Retrospective chiude lo sprint. Il team sceglie un piccolo numero di miglioramenti concreti, e i più importanti possono essere aggiunti allo Sprint Backlog successivo.

Backlog refinement non è un evento ma un'attività continua durante lo sprint. Il team chiarisce, suddivide e dimensiona gli elementi in arrivo, così lo Sprint Planning successivo procede rapidamente.

Per agende e consigli di facilitazione per ogni riunione, consulta la nostra guida alle cerimonie Scrum.

Chi fa cosa in uno sprint

Uno Scrum Team ha tre responsabilità. Tutte e tre sono necessarie perché uno sprint funzioni.

Nota che nessuno assegna le attività ai Developer; sono loro a organizzare il lavoro.

Come pianificare e gestire uno sprint, passo dopo passo

Questa è la sequenza che consigliamo a un team che affronta i suoi primi sprint. Segue la Scrum Guide, con l'aggiunta di abitudini pratiche.

1. Prepara il Product Backlog. Prima della pianificazione, assicurati che gli elementi in cima siano ordinati, chiari e abbastanza piccoli da essere completati nello sprint. Il refinement nello sprint precedente serve a questo.
2. Verifica la capacità. Elenca ferie, formazione e altri impegni per sapere quanto tempo ha davvero il team. La nostra guida al capacity planning Agile spiega come fare.
3. Concorda lo Sprint Goal. Nello Sprint Planning, il Product Owner propone l'obiettivo e il team lo formula in un'unica frase chiara.
4. Seleziona il lavoro. I Developer prendono gli elementi dalla cima del backlog fino a raggiungere un carico realistico, usando come riferimento la velocity o il throughput recenti.
5. Pianifica il come. Suddividi in attività il lavoro dei primi giorni e concorda chi inizia cosa. Non serve pianificare ogni attività in anticipo.
6. Lavora in piccoli lotti. Completa gli elementi prima di iniziarne di nuovi. Quando qualcuno è bloccato, gli altri lo aiutano; questo si chiama swarming.
7. Ispeziona ogni giorno. Usa il Daily Scrum e una Scrum board visibile per individuare per tempo i rischi per lo Sprint Goal.
8. Raffina il lavoro in arrivo. Dedica un po' di tempo in ogni sprint a preparare il prossimo gruppo di elementi; le edizioni precedenti della Scrum Guide suggerivano che di solito non richiede più del 10% della capacità del team, e molti team usano ancora questa regola empirica.
9. Fai la review con gli stakeholder. Mostra ciò che è Done, raccogli feedback e aggiorna il Product Backlog.
10. Migliora. Tieni la retrospettiva, scegli una o due azioni e portale nello sprint successivo, che inizia subito.

Un modello di sprint planning già pronto ti offre uno spazio per Sprint Goal, capacità, elementi selezionati e attività.

Esempio: uno sprint di due settimane, giorno per giorno

Ecco come potrebbe svolgersi un tipico sprint di due settimane per un team di prodotto di sei persone che lavora dal lunedì al venerdì. Gli orari sono indicativi; adattali al tuo calendario.

Esempi di Sprint Goal

• Prodotto software: "I nuovi utenti possono registrarsi con un'email di lavoro e invitare un collega, così possiamo avviare la beta dell'onboarding."
• Team marketing: "Pubblicare la landing page del webinar e il flusso di registrazione, così possiamo aprire le iscrizioni all'evento di giugno."
• Team HR: "Sperimentare la nuova checklist di onboarding con i due nuovi assunti che entrano questo mese."
• IT interno: "Migrare il team finanza alla nuova configurazione dei laptop senza perdere l'accesso alle unità condivise."

Si può modificare, prolungare o annullare uno sprint?

La Scrum Guide fornisce regole chiare per uno sprint in corso:

• Nessuna modifica che metta a rischio lo Sprint Goal. Il nuovo lavoro urgente può essere discusso, ma il team protegge l'obiettivo.
• La qualità non diminuisce. La Definition of Done non viene allentata per rispettare una data.
• L'ambito può essere chiarito e rinegoziato con il Product Owner man mano che il team impara. Gli elementi possono essere sostituiti o eliminati purché l'obiettivo resti valido.
• Il Product Backlog viene affinato secondo necessità.

Non è consentito prolungare uno sprint. Il time-box è fisso. Il lavoro non Done torna nel Product Backlog, dove il Product Owner lo riordina; non viene trasferito automaticamente nello sprint successivo e il lavoro parziale non conta ai fini della velocity.

Annullare uno sprint è possibile ma raro. Può farlo solo il Product Owner, e solo se lo Sprint Goal diventa obsoleto, ad esempio perché l'azienda cambia direzione o il mercato cambia. Il lavoro Done viene esaminato e gli elementi incompleti tornano nel Product Backlog.

Se gli stakeholder continuano a inserire nuovo lavoro negli sprint in corso, consideralo una forma di scope creep: indirizza invece le richieste attraverso il Product Owner e il Product Backlog.

Come monitorare l'avanzamento durante uno sprint

Non servono report complessi per gestire uno sprint, ma devi vedere se l'obiettivo è sulla buona strada.

• Board Scrum o Kanban. Colonne come Da fare, In corso, In revisione e Done mostrano il lavoro a colpo d'occhio e rendono visibili i colli di bottiglia.
• Sprint burndown chart. Rappresenta il lavoro rimanente ogni giorno rispetto a una linea ideale. Una linea piatta per diversi giorni è un segnale d'allarme precoce.
• Verifica dello Sprint Goal. A ogni Daily Scrum, chiediti se l'obiettivo è ancora raggiungibile; conta più di qualsiasi grafico.
• Velocity o throughput (dopo lo sprint). La quantità di lavoro completata per sprint, usata per pianificare gli sprint futuri. Vedi grafici di velocity Agile.
• Tasso di successo dello Sprint Goal. Su più sprint, la frequenza con cui il team ha raggiunto il proprio obiettivo è un'utile misura di prevedibilità.

Qualunque cosa monitori, usala per aiutare il team ad adattarsi, non per confrontare team o individui.

Vantaggi del lavoro a sprint

• Feedback rapido. Gli stakeholder vedono risultati funzionanti ogni poche settimane anziché alla fine del progetto.
• Focus. Un unico obiettivo e un orizzonte breve riducono il multitasking e i cambi di contesto.
• Rischio minore. I problemi emergono entro uno sprint, quando è meno costoso risolverli.
• Prevedibilità. Una cadenza costante rende più facile fare previsioni e pianificare i rilasci.
• Miglioramento integrato. La retrospettiva offre al team un momento regolare e protetto per migliorare il proprio modo di lavorare.
• Trasparenza. Obiettivi, backlog e board rendono l'avanzamento visibile a tutti.

Errori comuni negli sprint e come correggerli

Tutti i team Agile usano gli sprint?

No. Gli sprint appartengono a Scrum e ai metodi basati su iterazioni come XP e SAFe. Altri approcci funzionano diversamente:

• Kanban usa un flusso continuo con limiti al lavoro in corso invece di sprint fissi; pianificazione e rilasci avvengono quando servono. Confrontali in Kanban vs Scrum.
• Scrumban combina i due, spesso mantenendo una cadenza di pianificazione mentre gestisce il lavoro come un flusso.
• I design sprint sono un concetto diverso: un workshop strutturato di circa cinque giorni (reso popolare da Google Ventures) per esplorare e testare un concept di prodotto. Condivide il nome, ma non le regole di Scrum.

Per vedere come si confrontano questi approcci, leggi tipi di metodologie Agile.

Modelli e strumenti per gli sprint

Puoi gestire gli sprint con post-it e una lavagna, ma modelli e software rendono il lavoro più facile da condividere, soprattutto per i team da remoto.

• Modello di sprint planning: Sprint Goal, capacità, elementi selezionati, stime e attività.
• Modello di sprint retrospective: cosa è andato bene, cosa migliorare e azioni da intraprendere.
• Modello di product backlog: un elenco ordinato di elementi pronti per gli sprint futuri.
• Modello di user story: user story coerenti con criteri di accettazione e stime.
• Modello di piano di progetto Agile: rilasci, sprint e milestone in un'unica vista.

La maggior parte degli strumenti di project management oggi supporta gli sprint. Jira è costruito attorno a board Scrum e Kanban per i team software, mentre Wrike, il nostro strumento meglio valutato in assoluto, è adatto ai team che gestiscono sprint insieme ad altri tipi di lavoro tra reparti diversi.

Modelli gratuiti per questo argomento

Sfoglia tutti i modelli

Domande frequenti