Nell’ambito dello sviluppo agile, la stima del lavoro è un aspetto importante per determinati team e in determinati contesti. È una pratica che influenza sia la pianificazione che la previsione di ciò che può essere incluso in un incremento.
Tradizionalmente, molti team agili utilizzano gli Story Point come unità di misura per valutare l’impegno necessario per completare una User Story. Tuttavia, c’è un crescente interesse verso l’utilizzo di metriche alternative, come il Throughput, che si concentra su dati empirici basati sul lavoro effettivamente completato, piuttosto che su stime astratte.
Cosa si intende per Throughput?
Il Throughput è una metrica semplice e potente. Definito come la quantità di Work In Progress (WIP) completata per unità di tempo, questa misura tiene traccia del numero di elementi di lavoro che il team riesce a consegnare in un determinato periodo.
Daniel S. Vacanti, nel suo libro “Actionable Agile Metrics for Predictability”, chiarisce come il Throughput rappresenti un vero indicatore di produttività, basato sui dati raccolti durante il processo di lavoro e non su stime soggettive.
Nel contesto agile, il Throughput può essere espresso come il numero di Product Backlog Item, o User Story completate per iterazione o per Sprint.
Il confronto con gli Story Point
Come descritto in questo articolo, gli Story Point sono una metrica che valuta la complessità, il rischio e l’incertezza richiesti per completare un Product Backlog Item. Spesso, però, si riscontra una certa variabilità nel modo in cui vengono utilizzati dai diversi team. Questa ambiguità deriva dall’interpretazione soggettiva di cosa rappresenti effettivamente un determinato punteggio in termini di “effort” richiesto. Di conseguenza, alcuni team si ritrovano a dedicare molto tempo alle stime in fase di pianificazione, con il rischio di perdersi in dettagli irrilevanti piuttosto che concentrarsi su ciò che realmente conta.
Al contrario, il Throughput elimina gran parte di questa soggettività; piuttosto che cercare di valutare quanto sia complesso un task prima ancora che venga svolto, il Throughput misura il numero di elementi completati in un dato periodo, fornendo una base solida e oggettiva per la pianificazione futura.
L’utilizzo del Throughput nella pianificazione Agile
Uno degli aspetti più rilevanti di questa metrica è la sua capacità di fornire previsioni, in teoria più accurate, sulla capacità del team di completare il lavoro pianificato. E di conseguenza, un team agile può fare stime più attendibili, basate sui dati concreti, per quantificare ciò che potrà essere completato nell’iterazione successiva.
Questo aspetto, la prevedibilità, può essere rilevante in alcuni contesti o aree di business. Immagina per esempo organizzazioni che operano in un ambiente regolamentato, o che devono rispettare programmi di produzione. È il caso di settori come quello automobilistico o aerospaziale, o in ambito retail dove è importante allinearsi a campagne di vendita al dettaglio.
David J. Anderson, nel suo libro “Kanban: Successful Evolutionary Change for Your Technology Business”, sottolinea come il Throughput possa essere particolarmente utile quando si lavora con Kanban. Questo framework si basa su un flusso continuo di lavoro (Flow), e il Throughput diventa un indicatore chiave per ottimizzare e migliorare il processo di consegna.
Esempio di implementazione del Throughput
Facciamo un esempio concreto. Un Team Scrum, abituato a utilizzare gli Story Point, decide di sperimentare il Throughput. Nei primi cinque Sprint, il team completa rispettivamente 8, 9, 7, 9 e 10 elementi (Product Backlog Item o User Story). Dopo aver calcolato la media di Throughput, che risulta essere di circa 8,6 elementi per Sprint, i Developer pianificano 9 elementi per lo Sprint successivo.
Così facendo, lo Scrum Team evita il rischio di sovraccaricarsi di lavoro e riesce a gestire meglio le proprie aspettative rispetto a ciò che è possibile completare. È normale che agli inizi questa metrica sia estremamente variabile, ma con il passare del tempo, il team dovrebbe ottenere un Throughput più stabile e prevedibile.
Adottare il Throughput nel proprio team Scrum
Per implementare con successo la metrica del Throughput nel proprio team Scrum, il primo passo è iniziare a raccogliere dati sul numero di elementi di lavoro completati in alcuni Sprint consecutivi. Quattro o cinque dovrebbero essere sufficienti. Questi dati serviranno a creare una media di Throughput su cui basare le previsioni future.
È inoltre fondamentale che i Developer suddividano gli elementi di lavoro in unità relativamente piccole e uniformi in termini di dimensioni, affinché il Throughput possa riflettere con precisione la capacità del team. Questo non implica che tutti gli elementi debbano essere identici, ma ridurre al minimo le differenze di complessità rende più semplice ed efficace l’adozione del Throughput come metrica.
Throughput vs. Velocity
Un aspetto che spesso causa confusione è la differenza tra Throughput e Velocity. Anche se entrambi i termini vengono talvolta usati in modo intercambiabile, è importante notare che essi rappresentano concetti distinti. Mentre la Velocity si riferisce al numero di Story Point completati in un periodo (solitamente uno o più Sprint), il Throughput misura il numero effettivo di Product Backlog Item o User Story completate.
Secondo Vacanti, il problema principale nell’utilizzo della Velocity è che questa si basa su una metrica astratta come gli Story Point, il che la rende meno affidabile rispetto al Throughput, che si basa su dati concreti e facilmente misurabili. Un team potrebbe completare lo stesso numero di User Story in due sprint consecutivi, ma ottenere Velocity differenti a causa della variazione nella stima degli Story Point. Al contrario, il Throughput rimane coerente e fornisce una misura più oggettiva della produttività.
Throughput vs. Yesterday’s Weather
Un altro concetto spesso utilizzato nella pianificazione agile è il principio del Yesterday’s Weather, che si basa sul presupposto che il miglior indicatore per prevedere quanto lavoro si possa completare in un nuovo Sprint è il lavoro completato nello Sprint precedente. In altre parole, se un team ha completato 8 storie nello Sprint passato, si stima che probabilmente sarà in grado di completarne un numero simile nel prossimo Sprint.
Questo metodo si fonda sulla stabilità e sulla ripetibilità del ritmo di lavoro, ed è una tecnica empirica che evita stime complesse o eccessive congetture sul futuro. Tuttavia, Yesterday’s Weather guarda al passato recente, cioè allo sprint immediatamente precedente, e lo utilizza come unica base per le previsioni. Il Throughput, invece, estende questa logica, utilizzando una serie storica di dati sui task completati per fornire una previsione più robusta. Piuttosto che basarsi esclusivamente sullo Sprint immediatamente precedente, come fa Yesterday’s Weather, il Throughput analizza le tendenze di più Sprint, creando una base predittiva più solida.
Throughput e miglioramento continuo
Il Throughput non è solo un valido strumento per la pianificazione, ma supporta anche il miglioramento continuo. Durante le Sprint Retrospective, i Developer possono analizzare il loro Throughput e riflettere su come migliorare il loro flusso di lavoro. Per esempio, se il Throughput mostra una certa variabilità tra Sprint, è possibile che ci siano colli di bottiglia o inefficienze che ostacolano il lavoro.
L’ispezione di questi dati permette al team di apportare adattamenti mirati al proprio processo, e in questa ottica, il Throughput diventa un ottimo alleato per aumentare la produttività complessiva del team e la capacità di consegnare valore all’utente finale.
Considerazioni finali
Il Throughput rappresenta una valida alternativa agli Story Point per stimare e pianificare il lavoro in un contesto agile. Basato su dati oggettivi e misurabili, permette di eliminare gran parte della soggettività che caratterizza le stime basate sugli Story Point. Inoltre, il Throughput consente di identificare rapidamente colli di bottiglia e aree di miglioramento nel processo di consegna, migliorando così la prevedibilità e l’efficienza del team.
Come sottolineato da autori come Vacanti e Anderson, l’utilizzo di metriche di flusso come il Throughput è fondamentale per creare processi di lavoro più prevedibili e ottimizzati. A differenza della Velocity, il Throughput fornisce una misura più accurata e oggettiva della capacità del team di consegnare valore. Infine, attraverso l’analisi di questa metrica, un team agile può identificare eventuali aspetti su cui intervenire e migliorare continuamente il proprio processo.
È FINALMENTE DISPONIBILE IL VIDEOCORSO DI AGILE WAY!
CORSO APPROFONDITO SU SCRUM E SULLE METODOLOGIE AGILI
Aggiornato all’ultima versione della guida ufficiale di Scrum!
Più di 3,5 ore di video lezioni su Scrum, ideale per prepararsi a un esame di certificazione PSM I e per comprendere i valori, i principi e le pratiche dei metodi Agili. In questo corso imparerai:
- Origine, nascita e significato delle metodologie Agili
- Differenze tra Scrum e i modelli tradizionali
- Tutte le componenti del framework Scrum, i valori, le pratiche e le metriche
- Come gestire al meglio un progetto e un prodotto con Scrum
- Come mantenere un’attenzione continua al valore generato e al cliente
- Simulatore di esame di certificazione (80 domande)
- Tanto altro…
* Offerta limitata nel tempo
