La riunione di pianificazione dello sprint, passo dopo passo

La pianificazione dello sprint è la riunione che dà inizio a uno sprint. In tale occasione, il team concorda un obiettivo dello sprint e stabilisce quale parte del backlog sia realisticamente possibile portare a termine, trasformando un elenco di priorità in un piano in cui il team crede davvero. Il backlog rimane un semplice elenco di desideri finché qualcuno non decide quali elementi realizzare successivamente. Tale decisione viene presa proprio durante la pianificazione dello sprint.

Se condotta correttamente, richiede un’ora o due e il team ne esce consapevole di ciò che deve fare e del perché. Se condotta male, si trasforma in una sessione di lettura del backlog in cui il product owner assegna i ticket e tutti annuiscono, e l’“impegno” si sgretola silenziosamente già entro mercoledì.

Perché, cosa e come

La Guida allo Scrum struttura la pianificazione dello sprint attorno a tre domande, che è opportuno mantenere in questo ordine:

• Perché questo sprint è importante? La risposta sta nell’obiettivo dello sprint: una frase attorno alla quale l’intero team possa unirsi. Concordatelo prima di occuparvi del backlog. Stabilire un obiettivo dello sprint è una competenza a sé stante.
• Cosa è possibile realizzare in questo sprint? Gli sviluppatori prelevano dal backlog, a partire dalle voci in cima all’elenco, gli elementi che contribuiscono al raggiungimento dell’obiettivo, fino a quando non raggiungono il limite della loro capacità. Si tratta di una previsione, non di una promessa solenne.
• In che modo verrà portato a termine il lavoro selezionato? Il team suddivide le attività prioritarie in un piano sufficientemente dettagliato da consentire l’avvio del lavoro: attività specifiche, un approccio e i rischi evidenti. Non è necessario definire ogni singola attività fino all’ultima sottoattività; è sufficiente quanto basta per iniziare con sicurezza.

Il risultato è uno sprint backlog: l’obiettivo, le attività selezionate e il piano per la loro realizzazione.

Prima definire l’ambito, poi elaborare il piano

L’abitudine strutturale più utile in assoluto consiste nel condurre la pianificazione in due fasi distinte, anziché in un’unica fase poco definita.

La prima parte riguarda l’ambito. Il Product Owner presenta l’obiettivo e le voci candidate in ordine di priorità. Il team pone domande di chiarimento, verifica che ciascuna voce sia conforme alla definizione di “pronto” e seleziona il lavoro da svolgere fino all’esaurimento della capacità. Fermatevi qui. La tentazione di inserire «ancora una» piccola story è esattamente ciò che porta a sovraccaricare gli sprint.

La seconda parte riguarda la pianificazione. A questo punto il team approfondisce gli elementi selezionati, suddividendoli in attività, individuando le dipendenze e concordando chi si occuperà di cosa per primo. È qui che si scopre che quella storia che sembrava valere un 3 in realtà richiede una settimana di lavoro, nascosta dietro un criterio di accettazione vago.

Tenere separate le due cose impedisce che la riunione si trasformi in un continuo oscillare tra «dovremmo accettarlo?» e «come potremmo realizzarlo?» per ogni singolo punto all’ordine del giorno.

Cosa vi occorre nella stanza

La pianificazione dello sprint funziona solo se gli elementi di input sono già pronti. La riunione trasforma tali elementi in un piano; non li crea sul momento.

• Un backlog perfezionato e ordinato per priorità. Le voci principali dovrebbero essere già state comprese e la loro entità stimata a grandi linee. Se la pianificazione è la prima occasione in cui il team prende visione di una story, state effettuando il perfezionamento del backlog nella riunione sbagliata, e la riunione si protrarrà a lungo. Il perfezionamento è la fase preparatoria; la pianificazione è la fase decisionale.
• Un dato reale sulla capacità. Non “due settimane moltiplicate per la dimensione del team”, bensì le ore effettivamente disponibili al netto di ferie, riunioni, turni di supporto e interruzioni. Si veda velocity e pianificazione della capacità.
• L’intero team. Sono gli sviluppatori a formulare le previsioni, pertanto devono essere presenti. Una pianificazione affidata a terzi genera impegni di cui nessuno si assume la responsabilità.

Chi lo gestisce

Lo Scrum Master svolge un ruolo di facilitatore: garantisce il rispetto del timebox, mantiene separate le due fasi e impedisce che la riunione sfoci nella ricerca di soluzioni per ogni singolo caso limite. Il Product Owner definisce l’obiettivo e il backlog ordinato, e risponde immediatamente alle domande relative al «perché» e al «cosa». Gli sviluppatori decidono quale carico di lavoro assumersi e come realizzarlo.

Quest’ultimo punto è importante: la previsione spetta a chi svolge il lavoro. Un piano imposto dall’alto e accettato in silenzio non costituisce un impegno. È una semplice indicazione.

Quanto tempo dovrebbe richiedere

La Guida allo Scrum prevede una durata massima di otto ore per la pianificazione di uno sprint di un mese e, proporzionalmente, un tempo inferiore per gli sprint più brevi, quindi all’incirca due ore a settimana di sprint. Uno sprint di due settimane dovrebbe durare circa quattro ore, spesso anche meno una volta che il team ha raggiunto una cadenza stabile.

Consideratelo un limite massimo, non un obiettivo. I team che necessitano costantemente dell’intero intervallo di tempo a disposizione quasi sempre perfezionano il piano durante la pianificazione. Se si ottimizzano gli input, la riunione si accorcia di per sé. Se desiderate una suddivisione minuto per minuto, il capitolo Ordine del giorno della pianificazione dello sprint ne fornisce una.

Dove si verificano gli errori

Tre cause di insuccesso sono all’origine della maggior parte delle riunioni di pianificazione mal condotte.

La sessione di lettura. Il Product Owner illustra i ticket e il team ascolta. Non viene presa alcuna decisione perché nessuno sta decidendo; si tratta semplicemente di un briefing. La pianificazione dovrebbe dare l’impressione che sia il team a scegliere, non a ricevere incarichi.

L’eccesso di impegno. La capacità viene considerata come un obiettivo ambizioso. Il team prende come base la velocità massima mai raggiunta e vi aggiunge un po’ di ambizione. Poi, un imprevisto, un giorno di malattia e una story sottovalutata trasformano lo sprint in una corsa frenetica. Pianificate sulla base di una stima modesta, non di una cifra eroica.

Pianificazione senza un obiettivo. Il team seleziona un insieme eterogeneo di ticket non correlati tra loro e, quando lo sprint si fa serrato, non vi è alcun criterio per stabilire quali eliminare; di conseguenza, tutto subisce un leggero ritardo e nulla viene consegnato in modo impeccabile. È proprio l’obiettivo a indicare quali ticket abbandonare in caso di pressione.

Preparate i dati di input, tenete distinti l’ambito e il piano e affidate al team la responsabilità delle previsioni. Il resto di questa guida approfondisce ciascun aspetto. Iniziate con l’ordine del giorno oppure scaricate il modello per la pianificazione dello sprint.

Domande frequenti

Che cos’è la pianificazione dello sprint?

La pianificazione dello sprint è l’evento Scrum che dà inizio a uno sprint. Il team concorda l’obiettivo dello sprint, seleziona gli elementi del backlog che prevede di poter portare a termine e delinea le modalità di esecuzione del lavoro. In tale occasione vengono fornite risposte a tre domande: perché lo sprint è importante, cosa verrà realizzato e in che modo.

Quanto tempo dovrebbe durare la pianificazione dello sprint?

Prevedete un tempo massimo di circa due ore a settimana per ogni sprint, quindi all’incirca due ore per uno sprint di una settimana, quattro per uno sprint di due settimane e fino a otto per un mese. Si tratta di un limite massimo, non di un obiettivo. Se avete costantemente bisogno di utilizzare l’intero tempo a disposizione, solitamente significa che il backlog non era pronto all’inizio.

Quali sono le fasi principali della pianificazione dello sprint?

Verifichi la capacità effettiva del team per lo sprint; concordi un obiettivo dello sprint; selezioni le attività del backlog che contribuiscono al raggiungimento di tale obiettivo fino al raggiungimento della capacità; suddivida le attività prioritarie in un piano realizzabile; e si assicuri che il team condivida la previsione. Prima definisca l’ambito, poi pianifichi, in quest’ordine.

Chi conduce la riunione di pianificazione dello sprint?

Lo Scrum Master funge da facilitatore e garantisce il rispetto dei tempi prestabiliti. Il Product Owner presenta un backlog perfezionato e ordinato per priorità, spiegandone le motivazioni. Gli sviluppatori decidono quale carico di lavoro possono assumersi e come realizzarlo: spetta a loro formulare la previsione, non al Product Owner assegnarla.