Pianificazione dello sprint: la cerimonia che dà inizio allo sprint

La pianificazione dello sprint è la cerimonia che dà inizio allo sprint. Il team concorda su ciò che consegnerà e delinea le modalità, 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 di 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 capacità e gli esempi di obiettivi di sprint elaborati), si rimanda alla 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. Lo standup quotidiano verifica lo stato di avanzamento rispetto all’obiettivo dello sprint qui definito; la revisione dello sprint verifica se il team lo ha raggiunto. Se la pianificazione non viene effettuata correttamente, il resto dello sprint viene 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 da 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 interamente da ciò che vi si apporta.

• 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. Consulti la guida alla stima per comprendere perché i punti siano preferibili al tempo, disponibile qui.

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 che giovedì sarà assente. 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 la distrugge silenziosamente. Il fallimento più grave si verifica quando la stima fornita dal team viene riproposta come una promessa che non è mai stata fatta, trasformata in un impegno e utilizzata contro di esso; è proprio 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 dei compiti, significa che il perfezionamento del backlog non sta avvenendo. Risolvete 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 finisce regolarmente per andare a sbattere contro un muro, 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 che la sessione rispetti i tempi previsti e rimanga focalizzata sull’obiettivo. 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 che il team si impegna a raggiungere. Lo sprint backlog è l’insieme di elementi e attività che il team ritiene necessari per raggiungere tale obiettivo. L’obiettivo è fisso per lo sprint; lo sprint backlog può adattarsi ad esso man mano che il team acquisisce maggiori informazioni.