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 così 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 quale elemento 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” va silenziosamente in fumo 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 può unirsi. Concordatelo prima di iniziare a lavorare sul backlog. Definire un obiettivo dello sprint è una competenza a sé stante.
• Cosa è possibile realizzare in questo sprint? Gli sviluppatori prelevano dal backlog le attività in cima all’elenco 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 priorità principali in un piano sufficientemente dettagliato da consentire l’avvio del lavoro: attività, approccio e rischi evidenti. Non è necessario definire ogni singolo elemento fino all’ultima sottoattività; è sufficiente quanto basta per iniziare con sicurezza.

Il risultato è uno sprint backlog: l’obiettivo, gli elementi selezionati 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 attività candidate in ordine di priorità. Il team pone domande di chiarimento, verifica ciascuna attività rispetto alla definizione di “pronto” e seleziona il lavoro da svolgere fino all’esaurimento della capacità. Fermatevi qui. La tentazione di inserire «ancora una» piccola storia è proprio ciò che porta a sovraccaricare gli sprint.

La seconda fase è 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à nasconde una settimana di lavoro dietro un criterio di accettazione vago.

Tenere separate le due cose impedisce che la riunione si trasformi in un continuo botta e risposta tra «dovremmo accettare questa proposta?» e «come potremmo realizzarla?» 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à ben comprese e avere una stima approssimativa della loro entità. 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 è quella decisionale.
• Un dato reale sulla capacità. Non “due settimane moltiplicate per il numero dei membri del team”, bensì le ore effettivamente disponibili al netto di ferie, riunioni, turni di supporto e interruzioni. Si veda velocità e pianificazione della capacità.
• L’intero team. Sono gli sviluppatori a formulare le previsioni, quindi devono essere presenti. Una pianificazione affidata a terzi genera impegni di cui nessuno si assume la responsabilità.

Chi lo gestisce

Lo Scrum Master funge da facilitatore: garantisce il rispetto del timebox, mantiene separate le due fasi e impedisce che la riunione scivoli verso la 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 è fondamentale: la previsione spetta a chi svolge il lavoro. Un piano imposto dall’alto e accettato in silenzio non è un impegno, ma una semplice indicazione.

Quanto tempo dovrebbe richiedere

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

Consideratelo un limite massimo, non un obiettivo. I team che necessitano sistematicamente 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 riuscite.

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 problema di supporto, un giorno di malattia e una story sottovalutata trasformano lo sprint in una corsa frenetica. Pianificate partendo da una cifra modesta, non da una 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 esiste un criterio per decidere quali scartare; 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 lasciate che sia il team a farsi carico delle previsioni. Il resto di questa guida approfondisce ciascun aspetto: iniziate dall’ordine del giorno oppure scaricate il modello di 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 timebox 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, fino a un massimo di otto per un mese. Si tratta di un limite massimo, non di un obiettivo. Se avete costantemente bisogno di utilizzare l’intero timebox, significa che, di norma, il backlog non era pronto all’inizio.

Quali sono le fasi principali della pianificazione dello sprint?

Verificate la capacità effettiva del team per lo sprint; concordate un obiettivo dello sprint; selezionate le attività del backlog che contribuiscono al raggiungimento di tale obiettivo fino a raggiungere la capacità; suddividete le attività prioritarie in un piano realizzabile; e accertatevi che il team ritenga attendibile la previsione. Prima l’ambito, poi il piano — 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 quanto lavoro possono assumersi e come lo realizzeranno: spetta a loro formulare la previsione, non al Product Owner assegnarla.