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 opzionalmente una suddivisione in task. Il risultato dello Sprint Planning è lo Sprint Backlog.

Allo Sprint Planning meeting partecipa tutto il team. Altri stakeholder possono opzionalmente partecipare a questa riunione, se il team Scrum lo ritiene opportuno.

Durata e scopo dello Sprint Planning meeting

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 al massimo dalle due alle quattro ore, ma nella maggior parte dei casi, se il team ha avuto sessioni di backlog refinement precedenti alla pianificazione, una o al massimo due ore sono sufficienti.

A differenza del refinement, in sede di Sprint Planning si cerca di entrare nei dettagli di ogni singola attività. Se i Developer lo ritengono utile e opportuno, in fase di pianificazione si può cercare di determinare l’effort non più in termini di dimensione relativa (story point), bensì in termine di ore di lavoro.

Inoltre, prima di iniziare con i lavori, il team può decidere di calcolare quante sono le ore di sviluppo ideali (IEH - Ideal Engineering Hours). Questo passaggio è utile per 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à.

È all’inizio dello Sprint Planning che il Product Owner esplicita l’obiettivo che farà da bussola per la sessione di pianificazione. E per tutta la durata dello Sprint Planning, Developer e Product Owner devono lavorare insieme per identificare lo Sprint Goal, ovvero un obiettivo a breve termine (da raggiungere al termine dell'iterazione), che contribuisce in maniera incrementale al raggiungimento del Product Goal (obiettivo a lungo termine che il Product Owner definisce per il prodotto).

Lo Sprint Goal è generalmente espresso sotto forma di una frase che può essere scritta in cima al backlog - oppure in qualsiasi parte visibile dello spazio di lavoro.

La finalità dello Sprint Planning meeting è quindi la stesura dello Sprint Backlog, ovvero l’elenco di attività che il team prevede di portare a termine entro la conclusione dello Sprint. Attività che contribuiscono al raggiungimento dello Sprint Goal.

Come si svolge lo Sprint Planning

Lo Sprint Planning meeting consiste di tre argomenti principali:

• Perché questo Sprint è di valore
• Cosa può essere completato in questo Sprint?
• Come verrà svolto il lavoro selezionato

Argomento 1 - Perché?

In questa prima fase il Product Owner indica la direzione e rende esplicito come l'incremento che sta per iniziare (Sprint) aumenterà il valore del prodotto o della soluzione. In questa fase Developer e Product Owner iniziano a collaborare per la definizione dello Sprint Goal.

Argomento 2 - Cosa?

Durante la fase del "cosa", 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 viene identificata dai Developer come utile al raggiungimento del "perché", cercando di fornire quanti più dettagli possibile.

In questa fase si cerca quindi di impostare la direzione da seguire per il rilascio del prossimo incremento e il team può fare domande al Product Owner, cercando di smarcare gli ultimi dubbi.

In ogni caso, l'importante è avere abbastanza informazioni per poter iniziare a lavorare, non è infatti richiesto (e a volte neanche possibile) avere una conoscenza perfetta di tutti i dettagli per poter iniziare lo sviluppo.

Più i Developer sono consapevoli delle loro performance, della quantità di ore di sviluppo ideali che hanno a disposizione, e della Definition of Done, più è semplice ottenere una previsione sullo scope dello Sprint che sta per iniziare.

Non è importante che lo Sprint Goal sia completamente finalizzato, a questo punto del meeting. Il team ha a disposizione tutta la durata dello Sprint Planning per identificarlo.

Argomento 3 - Come?

Una volta ultimata la discussione sulla parte funzionale dei requisiti, si passa alla parte più tecnica e di implementazione, discutendo il lavoro necessario a produrre un incremento di prodotto in linea con la Definition of Done. Il Product Owner a questo punto può lasciare la sala riunioni, rimanendo comunque sempre a disposizione del team in caso fossero necessari ulteriori chiarimenti.

In quest'ultima fase gli sviluppatori procedono con la produzione vera e propria dello Sprint Backlog, finalizzando se necessario lo Sprint Goal; se lo ritengono utile per la pianificazione, scompongono ciascuna user story in task così come descritto in Lo Sprint Backlog in Scrum, e forniscono una stima in ore.

Cosa includere in pianificazione

Il prerequisito per una buona pianificazione è avere un Product Backlog ordinato correttamente dal Product Owner, con i requisiti più importanti già discussi e stimati in fase di refinement.

Approccio 1

Questo è l'approccio consigliato e più in linea con i valori di Agile e Scrum.

Secondo questo approccio, i requisiti che devono essere inclusi nella pianificazione sono scelti dal team a partire dallo Sprint Goal che prende forma in sede di Sprint Planning in seguito alla discussione tra Product Owner e Developer. Un esempio di Sprint Goal può essere:

Completare il modulo di registrazione

Un buon Sprint Goal è un obiettivo a breve termine che contribuisce al raggiungimento del Product Goal; il Product Goal è parte fondamentale del Product Backlog ed è reso esplicito dal Product Owner.

Con questo approccio il team seleziona tutte le user story che sono applicabili al fine di raggiungere l’obiettivo. Non si ragiona in termini di "output", ovvero di "quanti product backlog item dobbiamo completare"; ma di "outcome", ovvero "quale risultato vogliamo ottenere al termine dell'iterazione".

Approccio 2

Il Product Owner indica esplicitamente un sottoinsieme di user story che devono essere incluse in fase di Sprint Planning e che si trovano in cima al Product Backlog; 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, è bene ricordare che è il team di sviluppo che decide quanto è possibile aggiungere allo Sprint Backlog.

Sia che si scelga l'approccio 1 (consigliato, altrimenti qual è il beneficio di lavorare con agile?) o l'approccio 2 (sconsigliato, ma purtroppo dobbiamo scontrarci con la realtà), in ogni caso è sempre indispensabile 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 team di sviluppo 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 e il raggiungimento dello Sprint Goal. Le funzionalità non necessarie potranno così essere pianificate in Sprint successivi.