Quando si cerca di prevedere il futuro, si è raramente nel giusto. Le stime probabilistiche aiutano a migliorare le previsioni di uno Scrum Team.
Questo articolo da per scontato che il lettore conosce e pratica già Scrum, i concetti di velocità, story points e le problematiche legate alle stime.
Questa è la trascrizione (ndr. adattata da Fabio Panzavolta) dell’intervista di Michael Forni, nella quale ha condiviso la sua esperienza nell’uso di stime probabilistiche ed i vantaggi che ha potuto osservare. Grazie Michael!
Stimare e quantificare il lavoro da fare durante uno Sprint non è cosa facile. Cosa e come rispondere alla domanda del Product Owner: “quando sarà pronto?”.
Adottare stime probabilistiche, più efficaci delle classiche stime deterministiche basate su story points, può essere una soluzione.
Contesto
Il team che Michael ha aiutato, aveva raggiunto un livello di coesione, collaborazione e affidabilità nelle stime che li ha portati a voler andare oltre.
Questo è naturale perché Scrum è un framework che ci permette di adattarci in permanenza ai cambiamenti e diventare sempre migliori.
Se oggi il vostro team non è ancora capace di fare stime deterministiche, basate su story points e velocità, probabilmente allora non sarà ancora pronto per le stime probabilistiche.
Un consiglio: aiutate il team a maturare, facendo in modo di dare il gusto di migliorarsi continuamente e supportatelo nel viaggio unico che stanno intraprendendo, con pazienza e assiduità.
A quale problema si cerca di rispondere
Il Product Owner non trovava più soddisfacente, anche a livello personale, rispondere alla domanda: “ma il lavoro quando sarà pronto?”.
Usando il metodo tradizionale, con story point e velocità, se abbiamo 150 story points di lavoro e sappiamo che più o meno siamo in grado di fare 50 story points a Sprint, in tre Sprint avremo finito.
Questo però non ci aiuta a sapere quando una specifica “storia” sarà pronta oppure, in caso di cambiamento nell’ordine del Product Backlog, quando saranno pronti gli item che ora hanno più valore?
In questo caso la velocità e gli story points non sono così efficaci per rispondere a questa domanda.
Le stime probabilistiche, contrariamente a quelle deterministiche, indicheranno l’affidabilità dell’informazione che forniamo, indicando la probabilità di successo.
Professional Scrum With kanban
Questi concetti fanno parte di Kanban, che ci viene in aiuto e può essere un buon complemento a Scrum.
Kanban è un insieme di pratiche, abitudini e strumenti che aiutano a migliorare il flusso di lavoro e a rilasciare valore più rapidamente.
Per capire come utilizzare Scrum e Kanban insieme, Scrum.org propone il corso Professional Scrum With Kanban.
Esiste una guida, Kanban Guide for Scrum Teams, che può essere un buon complemento a questo articolo.
Michael ha seguito questa formazione che ha trovato utile per capire che Scrum con Kanban è ancora 100% Scrum ed ha ancora più valore.
Cycle Time
Il Cycle Time è una metrica probabilistica che si calcola misurando quando (con data tipicamente) un oggetto (ndr Product Backlog Item) entra nel sistema (ndr. Sprint) ed il giorno in cui esce. Usando la definizione di Ready e la definizione di Done per decidere cosa entra e cosa esce.
Questa metrica si calcola in giorni e corrisponde al “Cycle Time”. Questo è il calcolo che si è cominciato a fare nel team aiutato da Michael.
Item Age (éta)
Per vedere quanto manca a destinazione usiamo un’altra metrica di Kanban: l'”età dell’item”, o semplicemente “età”, che ci dice quanto sta invecchiando il nostro item nella Scrum board.
Più l’età aumenta, più è probabile che ci sia un problema, un ostacolo o comunque una situazione da analizzare e capire.
L’item esce dal sistema dopo un certo numero di giorni rivelando quello che è il cycle time: 3, 5, x giorni.
La prima indicazione è che quando un item ha un cycle time più lungo di uno Sprint vuol dire che non è abbastanza piccolo e il team cerca una soluzione a questo problema.
Lead Time
A differenza del cycle time, il Lead Time Corrisponde al tempo trascorso da quando l’item è entrato nel Product Backlog a quando è in produzione e gli utenti ne traggono effettivo beneficio.
Il lead time è un tempo superiore al cycle time.
Throughput (portata)
Un altra metrica Kanban, lo Throughput (portata), è utile per le stime probabilistiche e corrisponde al numero di item che hanno “attraversato il sistema” in un certo periodo di tempo.
Questa metrica è ciò che ci permette di abbandonare gli story points, a condizione di essere capaci di avere Product Backlog Items di dimensioni simili.
È una delle ragioni per le quali lo Scrum Team deve essere abbastanza maturo per aver capito e saper lavorare su Product Backlog Items di piccole dimensioni.
Si può arrivare a questo risultato passo dopo passo, per esempio continuando ad utilizzare il Planning Poker per stimare gli story points di un Product Backlog Item sfidandosi, durante il Product Backlog Refinement, ad ottenere items piccoli ed il più possibile della stessa dimensione.
Senza cambiare le abitudini dello Scrum Team, il focus può passare dagli story points alla quantità di Product Backlog Items che sono state terminate alla fine dello Sprint.
Michael Forni
Quindi si possono continuare ad usare Story Points e velocità, che piano piano perderanno importanza, sostituendoli con il numero di items e la loro probabilità di essere effettivamente terminati alla fine dello Sprint sulla base dei throughput precedenti.
Allora, per esempio, il Product Owner potrà affermare con gli Stakeholder che, per la fine dello Sprint, 7 items saranno terminati con una probabilità del 90%; 10 items con una probabilità del 70%, ecc.
Questo aiuta molto il Product Owner professionista a gestire le aspettative con gli Stakeholder, perché non si attiva più il conflitto basato sulle sensazioni, in quanto si utilizzano dati probabilistici per le previsioni tanto più affidabili quanto il sistema è performante nel suo insieme.
Vantaggi di stime probabilistiche
Uno dei vantaggi delle stime probabilistiche, contrariamente a quelle deterministiche, consiste ad essere capaci di fare previsioni future anche su ipotesi di contenuto di Product Backlog. Quando finiremo se abbiamo un Product Backlog con 100 items?
Ovviamente fermo restando che nello sviluppo di un prodotto complesso l’imprevisto è sempre dietro l’angolo e potrebbe cambiare le nostre previsioni.
Più il livello di conoscenza e di padronanza del prodotto e del business saranno grandi, più precisi saranno le previsioni.
Quello che si è capaci di affermare è, per esempio: “con un livello di 85% di probabilità/certezza, sappiamo che un Product Backlog Item che entra nel sistema oggi ne uscirà in 6 giorni o meno”.
Possiamo affermare quando sopra perché questo Scrum Team è in grado di garantire questo livello di output probabilistico.
Conclusione
Studi interessanti di Vasco Duarte, dimostrano che, confrontando uno Scrum Team che per dieci Sprint ha fatto stime deterministiche con story points e velocity con uno che ha utilizzato lo throughput, la capacità di prevedere il futuro è invariata o addirittura migliorata grazie alle stime probabilistiche.
Se il vostro team ha dimostrato, con dati alla mano, di essere capaci di valutare la complessità del lavoro dopo aver ridotto le storie alla dimensione minime possibile, allora è probabile (non certo ovviamente) che possano cominciare a contare le storie perché non c’è più bisogno di considerarle con una stima comparativa.
Ciò permette anche di apprezzare la “potenza” di uno Scrum Team professionale, non solo in termini di capacità a creare valore, ma anche di prevedere in modo probabilistico il futuro.
Per approfondire le stime probabilistiche
Qui di seguito trovate i riferimenti utili per approfondire questi argomenti:
- Actionable Agile Metrics for Predictability di Daniel S. Vacanti
- No Estimates di Vasco Duarte
- Michael Forni su Linkedin
- Formazione Professional Scrum with Kanban di scrum.org
Volete proporre il tema del prossimo podcast, contattateci!
