Sprint Planning: la Guida completa

Sono sempre stata contraria alle cosiddette “guide complete”, mi sono sempre sembrate un po’ troppo pretenziose. Forse perché sono fermamente convinta che non si finisce mai d’imparare! Nonostante ciò, ho deciso di scrivere una guida-non guida allo Sprint Planning.

Se il tuo scopo è quello d’imparare di più sullo Sprint Planning, uno dei meeting Agile più controversi e discussi, sei nel posto giusto.

Questo articolo, come ti scrivevo poco sopra, non è una guida “completa” allo Sprint Planning, bensì un punto di partenza basato sulla mia esperienza pratica che vuole creare spunti di riflessioni e attivare uno scambio di opinioni ed esperienze.

Ecco cosa troverai:

1. Cosa è Lo Sprint Planning
2. Sprint Planning Meeting: Chiarire l’obiettivo
3. Planning Poker nello Sprint Planning
4. Sprint Forecast & Sprint Review

Se vuoi scaricare il post che stai leggendo in PDF e accedere ad oltre 100 pagine su Agile, Team Cross-funzionale, Scrum/Kanban, Backlog, etc. ti presento Agile Starter Kit, una cartella condivisa su Google Drive pensata per gli eroi come te che stanno iniziando il proprio viaggio nel Digital Product Management.

Cosa è lo Sprint Planning & Sprint Planning esempio 

In poche parole è una cerimonia della Metodologia Agile Scrum che viene fatta all’inizio dello Sprint dove il Product Owner o Product Manager decide insieme al team di sviluppo, le user stories che il team farà nell’iterazione|sprint che sta per cominciare.

Partiamo dalle aspettative…

Per prima cosa andremo a fare il cosiddetto “break down” del meeting!

In pratica, grazie al break down andremo a rivelare l’agenda del meeting passo per passo. Sì, hai capito bene, proprio come quando si fa il break down delle “user stories” in piccoli task, noi lo faremo con lo Sprint Planning.

La struttura dello Sprint Planning comprende quattro parti che corrispondono alle varie sezioni di questo articolo:

1. Pre Planning: compiti per casa | Backlog Refinement
2. Chiarire l’obiettivo dello Sprint + MoSCoW
3. Stima dell’effort: Planning Poker
4. Sprint Forecast & Sprint Review

1. Pre Planning: compiti per casa | Backlog Refinement

Partiamo dalla considerazione più importante: allo Sprint Planning non si viene mai impreparati, MAI!!!!! 

Bisogna fare un botto di compiti per casa. Eh sì, se non vuoi spendere ore e ore chiuso in una stanza con i programmatori per decidere cosa fare nel prossimo Sprint, non puoi arrivare al meeting impreparato. 

Purtroppo, ho visto pochissimi Product Owner arrivare preparati al meeting. Questo perché spesso e volentieri la loro energia è incanalata nel parlare, negoziare con clienti e stakeholders. 

Focalizzarsi sul management delle aspettative degli stakeholders è giusto e sacrosanto, ma non può portare via tutto il tempo a disposizione di un Product Owner! 

E’ importante, se non fondamentale, che il PO abbia tempo da dedicare alla preparazione dello Sprint Planning.

Questa fase io la chiamo “Pre Planning” e comprende due attività:

• 1.1 Compiti per casa
• 1.2 Backlog Refinement

1.1 Compiti per casa

Nella prima attività, c’è tutto il lavoro preparatorio: parlare con gli stakeholders, raccogliere più dettagli possibili sui desideri dei clienti (requirements gathering) e “scrivere user stories”.

Non mi stancherò mai di dirlo, se sei un vero Product Owner e non un proxy (un portavoce del team), sei tu a scrivere user stories nella maggior parte dei casi. 

Più di una volta mi è capitato di ritrovarmi in Sprint Planning e vedere user stories senza né capo né coda, scritte da Business Analysts che copiavano e incollavano mail dei clienti. Arrivati al meeting, il PO leggeva le stories e gli si poteva letteralmente leggere in faccia che neanche lui/lei aveva capito cosa il cliente volesse e neanche i Business Analysts. 

Il team di sviluppo non faceva altro che sbuffare e impazientirsi perché cosa c’era da discutere?

Quindi, per prima cosa, prepararsi bene allo Sprint Planning deve essere una priorità, insieme allo scrivere user stories con criterio e confermare col cliente quali siano le specifiche.

1.2 Backlog Refinement

Un trucco che mi è stato da sempre super utile è quello di organizzare un Backlog Refinement col team di sviluppo a cadenza settimanale, questo a prescindere dal fatto che lo Sprint sia di una, due, tre o quattro settimane.

Cos’è il Backlog Refinement? E’ un meeting in cui ci si incontra e si rifiniscono e prioritizzano le user stories con tutto il team prima dell’effettivo Sprint Planning. Il backlog è spesso un insieme non ordinato di user stories e task che deve essere costantemente ordinato e prioritizzato.

Quali sono le best practices del Backlog Refinement?

1. Invitare tutto il team e mai farlo da soli

Questo spesso prevede coinvolgere UX team, Customer Representatives, team di sviluppo, Product Owner, Product Manager, Scrum Master e, perché no, a volte anche il cliente.

2. Avere una lista pronta di storie da rifinire

Come sempre arrivare preparati anche al Backlog Refinement 🙂

3. Farlo in maniera ricorrente.

Almeno una volta la settimana! Questo permette il PO di capire effettivamente se quella determinata user story è pronta per lo Sprint Planning oppure no.

4. Non farlo a ridosso dello Sprint Planning, altrimenti perde di significato

Ci deve essere abbastanza distanza tra il Backlog Refinement e lo Sprint Planning. In questo modo il PO avrà tempo di tornare indietro sui suoi passi, chiedere informazioni aggiuntive e arrivare di conseguenza preparato al Planning. 

5. Cominciare a stimare le stories in questo meeting piuttosto che stimarle tutte durante lo Sprint Planning. 

Perché dico questo quando tutti i manuali su Scrum/Agile dicono di farlo durante il Planning? Perché è fondamentale non perdere tempo al Planning e stimare le storie quando vengono rifinite è sicuramente più semplice piuttosto che riparlarne al Planning dopo che saranno passati giorni dall’ultima volta in cui se ne è parlato.

2. Chiarire l’obiettivo dello Sprint + MoSCoW durante lo Sprint Planning

Spesso l’obiettivo dello Sprint viene messo in secondo piano, perché ritenuto superfluo o perché ci sono talmente cose da fare che sembra quasi impossibile dare un goal univoco a uno Sprint così diversificato. 

Se lo Sprint pianificato è un’accozzaglia di task, allora siamo di fronte a un grosso campanello d’allarme: significa che il team non ha un solo obiettivo, ma molteplici, e questo non è un bene.

Stabilire insieme al team l’obiettivo dello Sprint, mi ha aiutato in non poche occasioni. 

E’ come dare al team dei guardrails che delimitano lo Sprint.

Una volta mi capitò di dover spiegare ad un team cosa fosse lo Sprint Goal perché non ne capivano l’importanza e credevano fosse una perdita di tempo. 

Più tardi, capii che il problema non fosse quello ma che c’era un malcontento generale. In passato ogni qualvolta era stato accordato uno Sprint Goal, puntualmente durante lo Sprint o veniva dimenticato, o veniva messo da parte, perché lo Sprint era stato completamente modificato.

Questo è un errore che tanti PO fanno e non li biasimo affatto. 

Capisco benissimo che a volte mantenere le priorità o i goal intatti per l’intera durata dello Sprint è praticamente impossibile. D’altro canto però modificare ogni santo sprint e cambiare in continuazione priorità non rende né credibili né bravi nel proprio lavoro. 

Dopotutto il lavoro del Product Owner è quello di avere la visione di prodotto e prioritizzare, quindi dire anche tanti “no”.

Un’altra tecnica che può essere di supporto alla scelta dell’obiettivo dello Sprint è quella di prioritizzazione MoSCoW.

Cos’è MoSCoW?

Si tratta di una tecnica di prioritizzazione del backlog dove le user stories vengono ordinate in base alle seguenti categorie: 

M sta per Must Have: le “user stories” che vengono raggruppate in questa categoria sono quelle non negoziabili. Senza di esse il progetto non ha senso, perciò devono essere completate.

S sta per Should Have: questo gruppo sono sicuramente importanti ma possono essere messe in secondo piano se serve.

C sta per Could Have: in questo caso le user stories sono considerate “nice to have” = tradotto = bell’idea, se avremo tempo le faremo “sicuramente”… oppure le considereremo in una seconda fase, ma per il momento “abbiamo cose più importanti da fare!”.

W sta per Won’t Have: queste stories, sono quelle che vanno archiviate immediatamente o messe in un backlog separato perché o non fanno parte della visione del Product Owner, oppure non sono fattibili dal punto di vista tecnico.

Utilizzare questa tecnica durante lo Sprint Planning salva tantissimo tempo ed energia perché permette di concentrarsi solo sull’essenziale, il superfluo viene lasciato per l’ultimo.

Tutte le volte che l’ho utilizzata, mi ha permesso davvero di fare una prioritizzazione spietata (che a volte serve) e di focalizzare l’attenzione solo sulle cose veramente importanti.

3. Stima dell’effort: Planning Poker nello Sprint Planning

Ok, questa è la parte più difficile di tutte! Non nascondo di aver fatto un sacco di errori in passato. Gli errori, però, mi hanno aiutato a crescere e ad affinare le tecniche utilizzate.

Partiamo dalle basi: “Cos’è il Planning Poker?”

E’ una tecnica Agile per stimare le user stories che utilizza la famosa sequenza di Fibonacci riadattata. Il Planning Poker è una metodologia basata sul consenso. Ogni membro del team ha un mazzo di carte ognuna con un diverso valore in ordine crescente: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100. Il valore rappresentato su ogni carta si riferisce ai cosiddetti “story points” che servono al programmatore per completare la “user story”. 

Più la storia è complessa e lunga, più story points saranno assegnati alla stessa.

Gli story points possono essere considerati come l’effort che il team mette nello spostare la user story dalla colonna del “To Do” a quella del “Done”.

Solitamente vengono effettuati 3 round (giri) in cui ogni giocatore rivela il valore (story points) che gli sembra appropriato per quella user story. 

Ogni giro, dopo aver scoperto le carte, il giocatore col valore più basso discute col giocatore che ha scelto il valore più alto e si procede in questo modo fino a quando non si raggiunge un accordo con l’intero team.

Se al terzo giro, il consenso non è ancora raggiunto, si va per la stima più conservativa. 

Un consiglio che mi sento di darti nel considerare “come stimare le user stories”, è quello di considerare tre variabili fondamentali:

1. Quanto è complessa la storia?
2. Quanto è rischiosa? Quante persone sono coinvolte? Prevedi che ci saranno tanti impedimenti?
3. Quanto è “time consuming” = quanto tempo richiede? 

Spesso in passato mi è capitato di commettere l’errore di dare importanza soltanto alla prima variabile, ma la complessità della storia non è la sola cosa che conta. E’ cruciale sapere anche quanto alto è il livello di rischio e le dipendenze che essa ha con altri team che potrebbero anche avere altre priorità.

Quindi, quando ti siederai assieme al team per stimare le user stories, tieni in considerazione tutte le variabili e, cosa estremamente importante, sfida chi stima le stories, mettili alla prova, aprendo loro gli occhi su tutte le cose che potrebbero andare male.

Spesso mi è capitato di avere a che fare con programmatori supereroi che stimavano storie molte complesse con pochissimi story points e poi lavoravano ore extra solo per completarle.

Un altro errore che ho ripetuto più e più volte, specialmente all’inizio è quello di comparare story points a giorni. Spesso il concetto di “Story points” è difficile da comprendere se non si è del settore e mi è capitato di doverli tradurre in ore e giorni per poter fornire una stima al Customer Success Team.

Cosa ho fatto, dopo un paio di iterazioni fallite miseramente? 

Ho smesso di comparare gli story points ai giorni.

Ho preparato una tabella di conversione per cui ogni valore in story points era associato al numero di giorni. 

Ecco qui un esempio molto semplificato della tabella di conversione: story points -> giorni:

Ovviamente questa tabella è correlata al grado di seniority degli sviluppatori e del team con cui avevo a che fare, perciò è molto soggettiva.

Il mio consiglio è di creartene una tutta tua dopo qualche iterazione, dopo che la velocità del team si sarà stabilizzata.

Anche se nella maggior parte dei casi, e come riportato sopra, non ha senso convertire story points in giorni, la tabella è un utilissimo strumento di conversione che può essere utilizzato da chi ha contatti col cliente per motivi di fatturazione.

4. Sprint Forecast & Sprint Review

Questa è l’ultima fase ma non per questo la più facile. Qui è il momento di fare decisioni difficili. 

Lo “Sprint Forecast”, che alcuni chiamano “Sprint Commitment”, è la parte finale dello sprint dove si fa la conta di tutti gli story points che si pensa si possano completare nella prossima iterazione e si da il via allo Sprint.

Questa attività può essere suddivisa in due task che io chiamo “Look back” (guarda indietro) & “Imagine the worst” (immagina il peggio).

4.1 Look back

Qui bisogna guardare agli sprint passati, quanti story points sono stati completati negli ultimi Sprint in media?

Se la media è 50, è inutile partire da una base di 60! 

4.2 Imagine the worst

Quanto è stata la “interference ratio” nello sprint precedente? Quanti story points sono stati aggiunti dopo che lo Sprint è iniziato? Quel valore è il buffer ovvero il cuscinetto che bisogna aggiungere alla media per sicurezza. Se qualcosa viene aggiunta dopo l’inizio dello Sprint, il team non dovrà fare overtime, ma potrà usare quel cuscinetto per completare gli story points aggiunti.

Certe volte mi piacerebbe avere una sfera magica e prevedere il futuro. Purtroppo, non ho ancora acquisito questo potere, anche se diventare un “fortune teller” mi avrebbe salvato non poche volte.

Il mio trucco è quello di pensare alla peggiore ipotesi che possa accadere e poi sperare che non accada. Se il team non saprà che farne del “buffer”, perché tutto è andato nei piani, sono sicura che tutti apprezzeranno un “garage day” dove sbizzarrirsi con le loro idee o improvement che da tempo speravano di portare a compimento.

Dal mio canto, spero che questo articolo sullo Sprint Planning ti sia piaciuto e ti auguro di diventare un mago dello Sprint Planning.

Chissà che un giorno, dopo tanta pratica, potrai stimare le stories a occhi chiusi!