Sprint Planning meeting

Lo Sprint Planning è un meeting in cui il team pianifica il lavoro che deve essere svolto e portato a termine durante lo Sprint. A differenza del Refinement, in cui si ragiona a livello di insieme (user story), lo Sprint Planning prevede un maggior livello di dettaglio e una suddivisione in task. Il risultato dello Sprint Planning è lo Sprint Backlog.

Come è intuibile, lo Sprint Planning avviene all’inizio di un’iterazione. La durata del meeting può variare a seconda delle attività da includere nella pianificazione e in base alla quantità di aspetti da discutere o chiarire. Generalmente, per uno Sprint di due settimane sono necessarie dalle due alle quattro ore.

Scopo dello Sprint Planning meeting

Come detto in precedenza, la finalità dello Sprint Planning meeting è la stesura dello Sprint Backlog, ovvero l’elenco di attività che il team si impegna a portare a termine entro la conclusione dello Sprint.

In questa sede si cerca di entrare nei dettagli di ogni singola attività e determinarne l’effort non più in termini di dimensione relativa (story point), come accade in sede di backlog refinement, bensì in termine di ore di lavoro.

È all’inizio dello Sprint Planning che il Product Owner esplicita l’obiettivo da portare a termine entro il termine dello Sprint, generalmente espresso sotto forma di una frase che può essere scritta in cima al backlog o in qualsiasi parte visibile dello spazio di lavoro.

Inoltre, prima di iniziare con i lavori, il team calcola quante sono le ore di sviluppo ideali (IEH – Ideal Engineering Hours). In questa fase è utile discutere e pianificare eventuali assenze di ciascun membro del team, in modo che il computo del totale delle ore a disposizione per il team rispecchi il più possibile la realtà.

Come si svolge lo Sprint Planning

Lo Sprint Planning meeting si svolge spesso in due fasi distinte.

Fase 1 – Cosa?

Durante la prima parte dello Sprint Planning, la presenza del Product Owner, così come di tutti i componenti del team, è fondamentale; il PO deve infatti spiegare dal punto di vista funzionale ciascuna user story che desidera includere nella pianificazione, cercando di fornire quanti più dettagli possibile. Se in azienda sono presenti Business Analyst, è importante coinvolgere anche loro in fase di discussione.

In questa fase il team cerca di fare domande e smarcare dubbi che possono essere sorti in fase di analisi macroscopica del requisito, in seguito a una sessione di Refinement Meeting, workshop interni o con il cliente finale.

Fase 2 – Come?

Una volta ultimata la discussione sulla parte funzionale dei requisiti, si passa alla parte più tecnica e di implementazione. Il Product Owner a questo punto può lasciare la sala riunioni, rimanendo comunque sempre a disposizione del team in caso fossero necessari ulteriori chiarimenti.

Il team procede a questo punto con produzione vera e propria dello Sprint Backlog, scomponendo ciascuna user story in task così come descritto in Lo Sprint Backlog in Scrum e fornendo una stima in ore.
In questo ambito è sicuramente utile rivedere la Definition of Done e verificare che sia applicabile allo Sprint corrente.

sprint planning meeting

Cosa includere in pianificazione

Il prerequisito per una buona pianificazione è avere un Product Backlog in ordine e priorizzato correttamente dal Product Owner.

Approccio 1

I requisiti che devono essere inclusi nella pianificazione possono essere scelti dal team a partire dallo Sprint Goal che viene espresso dal Product Owner all’inizio del meeting. Un esempio di Sprint Goal può essere:

Completare il modulo di registrazione

Il team seleziona quindi tutte le user story che sono applicabili al fine di completare l’obiettivo.

Approccio 2

Il Product Owner indica esplicitamente un sottoinsieme di user story che devono essere incluse in fase di Sprint Planning; questo approccio può essere dettato da:

  • Necessità di business
  • Bisogno di portarsi avanti con attività che dovranno essere completate in iterazioni successive
  • Richiesta specifica da parte del Team di sviluppo
  • Altre ragioni

Anche se si sceglie questo approccio, è sempre bene specificare uno Sprint Goal in modo da creare un obiettivo che, se raggiunto, rende lo Sprint ultimato con successo.

Quanto includere in pianificazione

Di norma si tende a pianificare un numero totale di story point il più vicino possibile alla media della velocity, ovvero il dato che rappresenta quanto il team è mediamente in grado di portare a compimento nell’arco di un’iterazione.

In caso le user story selezionate dal Product Owner o dal team fossero di molto inferiori al dato della velocity o alle ore di sviluppo ideali (IEH), il team può confrontarsi con il Product Owner e valutare se procedere con altre attività con priorità alta presenti nel Product Backlog.

Al contrario, se le user story superano il monte ore a disposizione per lo Sprint, potrebbe rendersi necessaria una revisione delle ore di sviluppo ideali (IEH) ed eventuali assenze programmate dall’ufficio.

Potrebbe anche rendersi necessario aprire un dialogo con il Product Owner e trovare un compromesso, magari rivedendo lo scope e ridefinendo quali sono le componenti fondamentali al fine del completamento dello Sprint. Le funzionalità non necessarie potranno così essere pianificate in Sprint successivi.