Come fare in modo che le stime abbiano successo?

Tutti coloro che hanno lavorato con Scrum, SAFE o altre metodologie "agile" che si basano su punti della storia stimati per giudicare la complessità di una funzionalità sa quanto possano essere complicate queste sessioni di poker di pianificazione. Allo stesso tempo tutti sono consapevoli di quanto sia cruciale una buona sessione di pianificazione da un lato per assicurarsi che il team concordi sui criteri di accettazione, la definizione di eseguito e dell'ambito (scope) e dall'altro per consentire al product owner di effettuare una decisione consapevole quando mette in priorità il backlog.

Quindi, esattamente come riesci a far diventare una sessione di Scrum Poker un successo? Per capire la ricetta giusta esamineremo cos'è una storia utente ben preparata, come presentarla, alcune procedure consigliate (best practice) per il poker stesso e come affrontare le discrepanze tra le stime.

Prima di eseguire la stima assicurati che la storia utente sia "pronta" e sia stata discussa

Questo potrebbe sembrare un consiglio banale ma, per avere una sessione di stima di successo, è importante che la funzionalità o la storia utente che vogliamo stimare sia pronta. Allora come si prepara una storia? In Scrum questo viene generalmente fatto durante le sessioni di perfezionamento (refinement), dove il product owner insieme al team di sviluppo (e spesso sotto la guida di uno scrum master) discutono i dettagli della storia.

Nel nostro team, questo inizia con il product owner che presenta in modo succinto ciò che l'utente vuole essere in grado di fare e qual è il valore per lui. Quest'ultimo è particolarmente importante in quanto dovrebbe dare un senso del perché ciò che stiamo facendo è importante. La struttura più diffusa per una storia utente è "In qualità di ..., voglio fare ..., in modo che ...".

Spesso il product owner avrà anche annotato alcuni criteri di accettazione di alto livello, che vengono poi discussi con il team di sviluppo. Probabilmente si potrebbero considerare buoni criteri di accettazione delle condizioni definite in maniera poco dettagliata che soddisferebbero il cliente consentendogli di raggiungere il valore definito piuttosto che una descrizione in dettaglio dei requisiti della soluzione. Insieme, il team di Scrum discute la storia utente esaminando i criteri di accettazione e può decidere di aggiungere o rimuovere alcuni di essi o chiarire elementi che sono chiaramente fuori dall'ambito (scope).

Una volta che tutti sono d'accordo sui criteri di accettazione e sulla definizione di done, possiamo passare alla stima vera e propria utilizzando, nel nostro caso, lo Scrum Poker (chiamato anche Planning Poker).

Stimare utilizzando Scrum Poker

Questo è il momento in cui lo strumento di stima su scrumpoker-online.org diventa utile. Raccomandiamo di aprire la all'inizio della sessione di rifinitura o di pianificazione e far entrare tutti i membri dello scrum team nella stanza usando l'ID della stanza fornita. Una volta che la storia utente è stata discussa e tutte le domande hanno avuto risposta, tutti i membri del team di sviluppo iniziano a stimare la complessità della storia assegnandole dei punti storia. Ok, punti storia e complessità, lo fai sembrare facile... ma cosa sono esattamente gli story points e come faccio a sapere quanti story punti dovrebbero essere assegnati ad una storia?

Punti della storia (Story points)

I punti della storia in Scrum sono una misura astratta per rappresentare la complessità dell'implementazione di una storia utente. In generale questa “complessità” è legata ovviamente allo sforzo, ma anche al rischio e alle difficoltà previste. La misura è astratta, perché non può essere correlata a un'unità di tempo come ad esempio i giorni-uomo.

Scrumpoker-online.org utilizza la sequenza di fibonacci (1,2,3,5,8,13,21) per stimare le storie. È anche molto utile avere una storia utente di riferimento che tutti i membri dello scrum team conoscono bene e assegnarle una stima. Il team può quindi iniziare a stimare le altre storie utente confrontandole con la storia utente di riferimento. Ad esempio, se la storia utente di riferimento è stata stimata a 3 punti, una storia che ha solo 1 punto dovrebbe essere tre volte meno complessa. Per questo motivo il valore assoluto delle storie è meno importante della loro relazione reciproca. Ricorda di rimanere agile e di iniziare a sperimentare: più storie il team stima, più diventerà bravo.

Scoprire i risultati

Dopo che tutti hanno consegnato le proprie stime, il product owner o lo scrum master mostra i risultati e se tutti coincidono, la storia è stata stimata con successo. Se invece ci sono delle discrepanze, i membri che più si sono allontanati possono iniziare a discutere sul perché le loro stime divergono. Molto spesso questa è un indicatore che non si è ancora raggiunta una comprensione comune di tutto ciò che questa storia utente comporta. Questa discussione può portare a ridefinire i criteri di accettazione e questo è assolutamente normale, dopotutto si tratta di un processo iterativo.

Ok fantastico, ora ho una stima ma perché è importante?

Una storia ben stimata aiuta notevolmente il product owner a giudicare meglio se il valore di una storia utente (o di una nuova funzionalità) vale la complessità e lo sforzo per implementarla. Inoltre, permette di avere una migliore comprensione della pianificazione di uno sprint: dopo il primo sprint, il team saprà esattamente quanti punti della storia (story point) sono stati in grado di raggiungere, quindi lo sprint successivo dovrebbe essere riempito con una somma simile di punti. Man mano che il team acquisisce conoscenze e diventa più efficiente, la consegna di una quantità di punti della storia potrebbe essere raggiunta più velocemente di prima. Ma questo è il secondo passo - per ora iniziate a stimare durante la vostra sessione di planning poker utilizzando scrumpoker-online.org e godetevi il piacere di cercare di concordare una stima... Vedrai, farà miracoli per produrre una comprensione condivisa di ciò che è previsto.