Sprint Planning. Partiamo proprio da qui, dal nome e dal suo significato. Cos’è lo Sprint Planning? Di cosa si tratta, quindi? Questo è un meeting a cui partecipa tutto il team e in cui si pianifica il lavoro che deve essere svolto e concluso durante lo Sprint.

Nello Sprint Planning, il PO o il PM con il team di sviluppo scenderanno nel dettaglio delle user stories e sceglieranno quelle da sviluppare nell’immediato successivo Sprint. In sintesi, come le user stories vengono divise in piccoli task con il break down, così lo Sprint Planning dividerà il meeting in step. 

Attraverso lo Sprint Planning si arriva infatti allo Sprint Backlog cioè alla lista dei task che il team porterà a termine durante lo Sprint. L’obiettivo da raggiungere viene chiamato Sprint Goal. 

Sprint Planning, la struttura. 

Lo Sprint Planning possiamo strutturarlo in 4 punti, tutti cruciali.

• Pre Sprint Planning

• Lo Sprint Goal, quindi l’obiettivo dello Sprint Planning

• Il Planning Poker

• Sprint Forecast e Sprint Review

Fase 1: il Pre Sprint Planning

Il PO non può mai e poi mai arrivare impreparato a uno Sprint Planning. Lui ha infatti un ruolo cruciale, quello del management, sia lato stakeholders che lato sviluppatori. Per arrivare pronto allo Sprint Planning il PO deve raccogliere quante più informazioni possibili dagli stakeholders, comprendere la desiderata e scrivere le user stories chiare, leggibili e comprensibili dal team. 

Altra attività funzionale allo Sprint Planning è l’aggiornamento costante del Backlog Refiniment. Con l’intero team, il PO organizza, ordina e prioritizza le user stories. Fatto in maniera ricorrente (almeno una volta alla settimana) e non a ridosso dello Sprint Planning (così da lasciare tempo al PO di raccogliere maggiori informazioni), permette di stimare le stories senza aspettare lo Sprint Planning. 

Fase 2: lo Sprint Goal

Lo Sprint Planning deve avere un obiettivo chiaro e condiviso da tutto il team. Mantenere le priorità e i goal in linea con l’obiettivo pianificato porterà ad avere una maggior coerenza, chiarezza e visione di insieme. 

Una tecnica usata a supporto dello Sprint Goal è quella della proritizzazione MoSCoW. Questa tipologia di analisi permette di risparmiare tantissimo tempo e lavoro, focalizzando l’attenzione solo sull’essenziale. Attraverso un’intransigente e severa prioritizzazione vengono gestiti i task in base alla priorità (o in altri ambiti la serie di elementi in questione che possono essere anche semplicemente le attività da fare durante la giornata). Ciò permetterà di monitorare il tempo e la qualità, non perdendo mai di vista la desiderata degli stakeholder. 

Pensateci un attimo: non tutti i requisiti e le caratteristiche di un prodotto hanno la stessa importanza. Per esempio pensiamo a un pc: chi usa tutti le sue funzioni? Molte effettivamente sono più usate e Quindi necessarie di altre. 

• M come Must Have: ciò che deve esserci. Di questo gruppo fanno parte tutte le user stories di vitale importanza, senza portare a compimento queste il progetto non può dirsi completo. 

• S come Should have: ciò che dovrebbe esserci. Di questo gruppo fanno parte le user stories importanti ma che possono essere messe in secondo piano rispetto al primo gruppo.

• C come Could have: ciò che potrebbe esserci. Indica le user stories non strettamente necessarie ma desiderabili, che sarebbe bello sviluppare, magari in un secondo momento. 

• W come Won’t have: fanno parte di questo gruppo tutte le user stories da archiviare o mettere in un Backlog separato. 

Fase 3: il Planning Poker

Se il nome vi fa pensare a una divertente partita di Poker beh mi dispiace ma non è così. Qui la questione infatti si fa alquanto complessa. Ma com’è che si dice: è quando il gioco si fa duro che i duri iniziano a giocare!

Il Planning Poker è un metodo basato sul consenso che permette di stimare l’effort delle user stories da sviluppare. L’effort, ovvero l’impegno, si calcola con l’unità di misura dello story point e si valuta in termini di complessità, rischio, incertezza e tempo. 

Più la storia è complessa e lunga, più sarà l’effort per spostarla da To Do a Done, più story point le saranno assegnati. 

Al Planning Poker si gioca in team, raggiungendo la stima di ogni user story con il principio del consenso e dell’unanimitá. Per stimare le user stories il team utilizza la riadattata sequenza di Fibonacci: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100. 

Come si gioca al Planning Poker? Ogni giocare (ovvero membro del team) ha un mazzo di carte e ogni carta ha un valore diverso. Il giocatore (ovvero membro del team) deve scegliere per ogni user story pesata scegliere una carta dal mazzo. Quindi il giocatore deve dare un valore alla user story e lo farà per ben tre giri, tre volte quindi. Come sempre la decisione finale verrà presa dal team unanimemente: si trova pertanto un accordo finale tra i giocatori (membri del team) per arrivare allo story point (la stima delle user stories). Ricordate di considerare tutte le variabili della user story per poter stimare lo story point: la complessità, il rischio, gli impedimenti, il tempo.

Fase 4: Sprint Forecast & Sprint Review

Eccoci arrivati alla parte finale dello Sprint Planning. In questa fase si fa un’analisi tirando le somme e valutando sia il passato che il futuro:

• Guardando indietro, agli sprint passati, valutate quanti story points sono stati completati in media;

• Guardando al futuro, pensate invece a tutti i possibili scenari che potrebbero verificarsi e valutate quanti story points. A Sprint iniziato quanti story points? Aggiungete alla  media degli story points un buffer, cioè un cuscinetto di sicurezza che vi permetterà di non perdere il controllo e di completare tutti gli story points anche quelli aggiunti in un secondo momento. E se non lo userete avrete del tempo in più per lavorare su tutto ciò che mettete in secondo piano.

E adesso… non ti resta che iniziare!