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 ne 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 capienza e gli esempi concreti di obiettivi di sprint — 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. Il daily stand-up verifica lo stato di avanzamento rispetto all’obiettivo dello sprint definito in questa sede; la revisione dello sprint verifica se il team lo ha raggiunto. Se la pianificazione viene effettuata in modo errato, 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 su cui entrambe possano fare affidamento. 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 product backlog perfezionato (elementi già chiariti e quantificati), la capacità del team per questo sprint e una valutazione della velocity recente.
• Risultati attesi: un obiettivo dello sprint e uno sprint backlog in cui il team crede davvero.

La definizione delle dimensioni avviene in sala. La maggior parte dei team giunge rapidamente a una stima condivisa utilizzando il planning poker anziché discutere per ore — consultate la guida alla stima per capire perché, in questo contesto, i punti siano preferibili al tempo.

La modalità di guasto da tenere d’occhio

Sovraccarico. 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ì non sarà presente. 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 lo distrugge silenziosamente.

Un altro segnale è 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: 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, fino a un’intera giornata per uno sprint della durata di un mese. Se la pianificazione va regolarmente a rotoli, significa che il backlog è stato presentato senza essere stato perfezionato e che il team sta svolgendo un lavoro di perfezionamento che avrebbe dovuto fare 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 incentrata 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 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.