Pianificare in Scrum

Uno dei primi errori che si fanno usando Scrum è pensare che non serva pianificare. In realtà usare Scrum significa pianificare continuamente dandosi sia degli obiettivi a medio-lungo termine con Vision e Roadmap di progetto; sia degli obiettivi a breve e brevissimo termine con Pianficazione dello Sprint e della giornata.

Vediamo come funziona un processo di pianificazione iniziale di un progetto Scrum una volta che la Vision e il Product Backlog del progetto sono definiti. I passi tipicamente sono:

  1. Stima della complessità delle storie
  2. Stesura della classifica delle storie nel product backlog (ranking)
  3. Stima della velocità di/dei team
  4. Stima di budget e data di consegna
  5. Roadmap di progetto

E’ bene che tutti i passi siano completati da tutto il team Scrum nella sua interezza: Scrum Master, Product Owner e membri del Team. Tipicamente questa fase dura 1-2 giorni su progetti della durata di 8-12 mesi che vedono un solo Team Scrum coinvolto. Ricordiamoci che il product backlog è già stato definito e le storie scritte. In casi di progetti più grandi possiamo arrivare a due settimane di lavoro.

Product Backlog
Product Backlog

E’ bene sottolineare che le storie con un ranking più basso saranno affrontate dopo nel progetto e avranno una stima più incerta. Le storie per i prossimi 2-3 sprint invece sono molto più granulari e dettagliate. Non fate l’errore di voler definire tutto subito oppure di non definire nulla: è bene trovare un buon bilanciamento tra accuratezza della stima e flusso del valore. Se rimanete troppo fermi a pensare la catena del valore e del feedback si ferma; se non pensate a cosa state facendo la vostra catena non apporterà nessun valore.

Stima del costo e della complessità delle User Stories

E’ il primo passo per poter stendere una roadmap realistica. Tipicamente si usa il Planning Poker Game per stimare costo e complessità delle storie.

Serie di Fibonacci a Muro
Serie di Fibonacci a Muro

Il team si ritrova con il product backlog a muro e pesa ciascuna storia usando la serie di Fibonacci: 1, 2, 3, 5, 8, 13 , 21, BIG, ? (una variante prevede la serie 1, 2, 3, 5, 8, 13, 20, 40, 100, ?). Chiameremo questi numeri Story Points.

Carte con la serie di Fibonacci
Carte con la serie di Fibonacci

Il meccanismo è semplice:

  1. Ogni membro del team ha un mazzo di carte con la serie di Fibonacci.
  2. A muro si mettono i post-it con la serie di Fibonacci e a fianco tutte le storie da valutare.
  3. Si sceglie la storia più semplice e meno costosa e la si pesa 1 story point mettendola sotto la colonna 1.
  4. Dopo di che si prende una storia media e la si mostra al team descrivendola. Questa fase dura pochi minuti. I membri del team non devono fare ipotesi sul costo ma solo chiedere chiarimenti.
  5. Chiarita la storia si passa alla stima. Ciascun membro del team sceglie di nascosto i valore che pensa sia corretto per quella storia in base all’1 scelto. Ad esempio se la storia in stima si pensa sia poco più complessa e costosa della storia che vale 1 story point si sceglie la carta 2. Se è molto costosa si può scegliere 13 o 21. Se non si riesce a valutare si sceglie “?”. Con una terza storia si riesce a triangolare perché permetterà di definire dei punti di riferimento per le storie successive: un po meno di questa storia ma di più di questa. Ovviamente possono esserci storie che hanno lo stesso Story Point assegnato.
  6. Una volta che tutti hanno fatto la loro scelta si girano le carte.
  7. Se tutti hanno scelto lo stesso valore si mette la storia sotto la colonna corrispondente al valore concordato.
  8. Altrimenti la persona che ha messo il valore più basso e quello più alto si confrontano.
  9. Una volta che le due persone hanno detto i loro motivi, gli altri membri del team possono collaborare al dialogo chiedendo chiarimenti al Product Owner.
  10. Dopo qualche minuto si riprova a giocare (passi 5, 6, 7, 8, 9, 10). Ricordatevi di riprendere in mano la carta che avete giocato!
  11. Dopo qualche tentativo si dovrebbe arrivare alla convergenza.
  12. Se non si riesce non fate una media ma mettetelo nel ? per essere rivalutato. Non bloccatevi troppo tempo su una singola storia. Se crea troppa discussione vuol dire che ha bisogno di approfondimenti e quindi non è “ready” per gli sprint imminenti.
  13. Una volta finite tutte le storie segnate sulla storia il valore in story point concordato e fate la somma degli Story Points.
Valutazione di una seconda User Story
Valutazione di una seconda User Story
Al completamento della stima segno gli Story Points sulle storie
Al completamento della stima segno gli Story Points sulle storie
Momento di planning poker
Momento di planning poker

Ranking

Una volta che siamo arrivati a definire il peso di ciascuna storia possiamo definire una classifica di importanza delle storie all’interno del Product Backlog. Questo Ranking viene fatto sulla base di diverse variabili:

  • Valore di Business (lo potete definire in diversi modi, lo vedremo nei prossimi articoli)
  • Costo (Story Points)
  • Rischio di Business
  • Rischio Tecnologico
  • Costo del ritardare una Storia
  • Conoscenza e dettaglio della storia
  • Dipendenza tra le Storie

Una soluzione è quella di favorire le storie che costano meno e che producono alto valore di business. Fattori come rischio tecnico e di business devono essere comunque valutati. Si tende a scrivere storie cosiddette INVEST (Independent, Negoziable, Valuable, Estimable, Small, Testable) ma capita che alcune storie siano tra di loro legate e quindi il ranking va di conseguenza alla loro dipendenza.

Se avete 50 storie si riesce a definire questa classifica agevolmente con un confronto a coppie che tiene conto degli aspetti elencati.

Confronto a CoppieConfronto a Coppie

Con questo strumento confronto coppia per coppia e pongo nella matrice triangolare quella che dal confronto vince. Poi conto quante storie ci sono nella matrice e ho la mia classifica.

Se avete tante storie questa matrice è molto grande. Suggerisco di usare uno strumento a monte che permetta di aiutare a definire delle priorità a livello di Epiche. Ad esempio: il Modello di Kano o la MoSCoW. Parleremo di queste tecniche nei prossimi mesi.

Budget e data di consegna

Adesso avete il totale di Story Points e il Ranking del backlog. Possiamo ora rispondere alle domande: Quando costa il progetto? Quando verrà consegnato?

Non dobbiamo pensare di essere assolutamente precisi al giorno nella stima, non abbiamo la sfera di cristallo. Dobbiamo essere però accurati cercando di non dimenticarci pezzi importanti. Se ci pensate una previsione del tempo affidabile è al max di tre giorni, come possiamo pretendere di essere così ì bravi a stimare un progetto di un anno?

Diamo quindi una stima con una certa tolleranza e man mano che il progetto procede potremo essere più precisi.  (Apro una parentesi breve sui contratti a Prezzo Fisso. Si possono fare in Scrum, anzi sono preferibili. Con la mia software house si fanno e funzionano quando si collabora bene con il cliente. Sono comunque un aspetto delicato che merita un approfondimento ulteriore).

I passi per il budget sono:

  1. Calcolare il costo per Sprint (= durata in giorni dello sprint  X numero di persone nel Team X costo delle persone al giorno).
  2. Stimare la velocità del Team.
  3. Calcolare il numero di Sprint ( = totale story points / velocità stimata). Una approssimazione del 20-30% sul numero degli sprint è una buona regola. Quando poi si parte con gli sprint si può valutare quanto la velocità stimata e quella reale siano vicine e aggiustare di conseguenza il numero di sprint.
  4. Calcolare il Budget (= numero sprint X costo a sprint)
  5. Calcolare la data di consegna ( = numero sprint proiettati sul calendario tendendo conto di festività e ferie)
Stima velocità
Stima velocità

Roadmap

Ora che abbiamo gli elementi che definiscono il contorno del progetto: Costi, Tempi e Ambito possiamo definire una Roadmap. Non confondete la roadmap con un piano di dettaglio ma invece pensatela come un macro-piano iniziale per fissare degli obiettivi intermedi al team e potersi allineare con le esigenze di business.

Grazie al fatto che lavoriamo con le Storie possiamo riassumere con una frase l’obiettivo di ciascuno Sprint e di un insieme di Sprint. Ad esempio se uno Sprint vede storie che coinvolgono la creazione del profilo utente e della sua registrazione al sito possiamo chiamare lo Sprint: Registrazione e Profilo Utente.

Viene così intuitivo raggruppare un insieme di Sprint in versioni intermedie e dargli un nome rilevante per il business.

Più la Roadmap si spinge in là con il tempo più questa può essere incerta e modificata. E’ bene saperlo fin dall’inizio e fissare solo traguardi realistici e chiari lasciando la futuro la definizione di quello che è incerto.

Ecco la sequenza di una roadmap definita con i post-it.

Passo 1 - In base alla velocità stimata di 8 pianifico il primo e il secondo Sprint
Passo 1 – In base alla velocità stimata di 8 pianifico il primo e il secondo Sprint
Passo 2 - Una storia non ci sta nello SprintPasso 2 – Una storia non ci sta nello Sprint
Passo 3 - Splitto la storia
Passo 3 – Splitto la storia
Passo 4 - La storia splittata riempe anche il terzo Sprint. Il quarto sprint è da analizzare successivamente perché ha una storia troppo grande. Possiamo comunque partire
Passo 4 – La storia splittata riempe anche il terzo Sprint. Il quarto sprint è da analizzare successivamente perché ha una storia troppo grande. Possiamo comunque partire
Passo 5 - Definisco una roadmap in base al contenuto degli sprint
Passo 5 – Definisco una roadmap in base al contenuto degli sprint

Ci sarebbe molto altro da scrivere sulla pianificazione in Scrum come ad esempio lo Sprint Zero. Ma manteniamo per ora le cose semplici e facciamo un passo alla volta!