Pianificazione dello sprint: la cerimonia che dà inizio allo sprint
La pianificazione dello sprint è la riunione che dà inizio allo sprint: il team concorda un obiettivo dello sprint e trasforma le voci del backlog in un piano che ritiene di poter portare a termine.
La pianificazione dello sprint è la riunione che dà inizio allo sprint. Il team concorda su ciò che consegnerà e definisce a grandi linee come farlo, trasformando una parte del product backlog in uno sprint backlog e in un unico, chiaro obiettivo dello sprint. Se condotta correttamente, richiede poche ore e garantisce al team due settimane di concentrazione. Se condotta male, si trasforma in un esercizio di riempimento della lista delle attività, che il team trascorre il resto dello sprint a rinegoziare in silenzio.
Il presente capitolo costituisce una sintesi a livello di cerimonia. Per il programma completo della sessione (l’ordine del giorno, i ruoli, i calcoli relativi alla capienza e gli esempi di obiettivi di sprint elaborati), si veda la guida completa alla pianificazione dello sprint.
Il ruolo della pianificazione nel ciclo
La pianificazione dello sprint è la prima delle cerimonie agili, e il suo risultato costituisce il punto di riferimento per tutte le altre. Il daily stand-up verifica lo stato di avanzamento rispetto all’obiettivo dello sprint stabilito in questa fase; la revisione dello sprint verifica se il team lo ha raggiunto. Se la pianificazione viene effettuata in modo errato, il resto dello sprint verrà dedicato a correggere l’errore.
A quali domande risponde la pianificazione: perché, cosa, come
La Guida allo Scrum struttura la riunione attorno a tre domande (perché questo sprint è importante, cosa si può fare e come verrà realizzato), e l’ordine è fondamentale.
Chiarite innanzitutto il perché. Un obiettivo di sprint che si possa sintetizzare in una sola frase vale più di un backlog che non si riesce a portare a termine. L’obiettivo è ciò che il team tutela quando il piano si scontra con la realtà a metà sprint; l’ambito si adatta ad esso, non è l’obiettivo ad adattarsi all’ambito.
Poi il cosa: il product owner definisce le priorità, gli sviluppatori selezionano le attività che ritengono di poter portare a termine, e le due parti negoziano fino a raggiungere un accordo che entrambe ritengono affidabile. E il come: gli sviluppatori suddividono le attività prioritarie in un piano sufficientemente dettagliato per poter iniziare: non un diagramma di Gantt, ma solo una bozza di progettazione sufficiente a confermare che il lavoro sia concreto.
Ingressi e uscite
La qualità di una pianificazione dipende da quanto ci si impegna a realizzarla.
- Dati di input: un backlog dei prodotti perfezionato (elementi già chiariti e quantificati), la capacità del team per questo sprint e una valutazione della velocità recente.
- Risultati attesi: un obiettivo di sprint e uno sprint backlog in cui il team crede davvero.
La definizione delle dimensioni avviene in sala. La maggior parte dei team raggiunge rapidamente una stima condivisa utilizzando il planning poker anziché discutere per ore. Si veda la guida alla stima per comprendere perché, in questo contesto, i punti siano preferibili al tempo.
La modalità di guasto da tenere sotto controllo
Eccessivo impegno. I team pianificano al 100% della capacità teorica e dimenticano che la velocità tiene già conto delle riunioni, delle interruzioni e della persona assente il giovedì. Pianificate in base alla capacità, non alle speranze: un piano che il team porta a termine rafforza la fiducia, mentre un piano che il team abbandona in silenzio la distrugge. Il fallimento più grave si verifica quando la stima fornita dal team viene riproposta come una promessa che non ha mai fatto, trasformata in un impegno e usata contro di esso: è qui che la pianificazione scivola nel teatro agile.
Un altro segnale rivelatore è un piano basato su un backlog non perfezionato. Se la fase di pianificazione si trasforma in una sessione dedicata al chiarimento e alla suddivisione, il perfezionamento del backlog non viene effettuato. Risolva il problema a monte e la pianificazione procederà senza intoppi.
Domande frequenti
Quanto tempo dovrebbe durare la pianificazione dello sprint?
Prevedete un tempo di circa due ore a settimana per ogni sprint, quindi fino a quattro ore per uno sprint di due settimane e fino a un’intera giornata per uno sprint della durata di un mese. Se la pianificazione si protrae regolarmente fino all’ultimo momento, significa che il backlog è stato consegnato senza essere stato perfezionato e che il team sta svolgendo un lavoro di perfezionamento che avrebbe dovuto svolgere in precedenza.
Chi partecipa alla riunione di pianificazione dello sprint?
L’intero team Scrum: gli sviluppatori, il Product Owner e lo Scrum Master. Il Product Owner definisce le priorità e ne spiega le motivazioni; gli sviluppatori decidono cosa possono realisticamente intraprendere e come lo realizzeranno; lo Scrum Master garantisce il rispetto dei tempi e mantiene la sessione ben focalizzata. Le parti interessate non partecipano.
Qual è la differenza tra l’obiettivo dello sprint e lo sprint backlog?
L’obiettivo dello sprint è la singola frase che spiega perché vale la pena eseguire lo sprint: il risultato a cui il team si impegna a giungere. Lo sprint backlog è l’insieme di elementi e attività che il team ritiene possano consentirgli di raggiungere tale obiettivo. L’obiettivo è fisso per lo sprint; lo sprint backlog può adattarsi ad esso man mano che il team acquisisce maggiori informazioni.