Per analizzare questa domanda, Saint Jude ha esaminato 727.282 issue di Jira, distribuite tra 204 progetti software e 19 domini differenti. Abbiamo confrontato gli story points con i dati reali di esecuzione per capire se progetti che utilizzavano stime simili presentassero anche comportamenti simili nel tempo. L'obiettivo non era partire dall'opinione che gli story points funzionino o non funzionino, ma osservare cosa accade quando una stima relativa inizia a essere utilizzata come se fosse una metrica standardizzata di delivery del progetto.

Il risultato mostra una differenza importante tra stimare un'attività e misurare il comportamento di un progetto. Gli story points possono avere senso all'interno del riferimento creato da un team, ma questo non significa automaticamente che gli stessi valori possano essere confrontati tra team, progetti o portfolio differenti.

Story points in ore: perché questa conversione diventa un problema

Gli story points in Scrum e Agile vengono utilizzati per rappresentare differenze relative tra le attività. Molti team utilizzano la sequenza Fibonacci — 1, 2, 3, 5, 8 e 13 — per assegnare gli story points in base alla complessità, all'incertezza e allo sforzo previsto. L'aspetto più importante è che questi valori acquistano significato in relazione alle altre attività stimate dallo stesso team. Un'attività da cinque punti viene quindi considerata più complessa, incerta o impegnativa rispetto a un'attività da tre punti all'interno dello stesso riferimento.

La difficoltà inizia quando questa scala relativa viene convertita in tempo. È comune sentire domande come quante ore corrispondano a uno story point, se cinque punti rappresentino uno o due giorni di lavoro oppure quanti story points dovrebbero essere completati durante uno sprint. Sono domande comprensibili, perché project manager e responsabili devono lavorare con scadenze, capacità e previsioni di consegna, ma il concetto stesso di story point non stabilisce una conversione universale tra punti e ore.

Un team può completare storicamente un determinato tipo di attività da cinque punti in pochi giorni, mentre un altro può utilizzare gli stessi cinque punti per classificare un lavoro che richiede molto più tempo. La story point estimation funziona a partire dal riferimento costruito dal team e non da una scala comune utilizzata da tutte le organizzazioni.

Se fosse possibile convertire gli story points in una metrica standardizzata di delivery, i progetti che utilizzano valori simili dovrebbero presentare tempi di esecuzione almeno ragionevolmente vicini. Non sarebbe necessario che tutte le attività richiedessero esattamente lo stesso tempo, perché qualsiasi progetto presenta variazioni, ma dovremmo trovare una relazione abbastanza consistente da poter utilizzare quei punti come riferimento comune. È proprio in questo punto che i dati hanno iniziato a mostrare un comportamento differente.

Cosa rivelano gli story points in Jira sul cycle time reale

Abbiamo iniziato osservando i progetti la cui mediana degli story points era esattamente uno. Questo confronto offre un riferimento semplice: se il valore uno avesse un significato ragionevolmente coerente tra progetti indipendenti, le rispettive mediane di cycle time non dovrebbero essere completamente scollegate tra loro.

Abbiamo invece trovato esattamente il contrario. Progetti con la stessa mediana di story points presentavano tempi mediani di completamento radicalmente differenti.

Progetto Mediana story points Mediana cycle time Progetto 1 1 0,7 ore Progetto 2 1 115,5 ore Progetto 3 1 161,9 ore Progetto 4 1 197,4 ore Progetto 5 1 4.464,8 ore Progetto 6 1 8.246,3 ore

Tutti questi progetti presentano la stessa mediana di stima, ma le loro mediane di cycle time sono estremamente diverse. A un'estremità, la mediana è inferiore a un'ora. All'altra, supera le 8.000 ore. Anche lasciando da parte i valori più estremi e osservando soltanto i progetti intermedi, troviamo comunque differenze sufficienti per mostrare che il valore uno non possiede un significato standardizzato di delivery tra progetti diversi.

Per me, questo è uno dei punti più importanti dell'analisi. Uno story point può avere senso all'interno dello storico del team che lo ha creato, ma quando togliamo quel numero dal suo contesto ci dice molto poco su quanto tempo dovrebbe realmente richiedere un'attività. La stima continua a esistere, ma il riferimento che dava significato a quel numero scompare.

Lo stesso comportamento appare quando aumentano gli story points

La differenza non riguarda soltanto le attività stimate con un punto. Anche i progetti con una mediana vicina a tre story points hanno mostrato cycle time molto diversi. In uno dei progetti analizzati, la mediana dei tempi di completamento era di circa 120 ore. In un altro arrivava a quasi 292 ore. Un terzo progetto raggiungeva circa 454 ore, pur utilizzando la stessa mediana di story points.

Questo diventa particolarmente rilevante quando gli story points escono dal contesto del team ed entrano nella governance dei progetti. Un PMO può osservare diversi board Jira e trovare il valore tre in tutti, interpretando quelle attività come se fossero direttamente comparabili. In realtà, ogni team può aver costruito la propria stima utilizzando riferimenti storici, livelli di esperienza, architetture, tecnologie e criteri completamente differenti.

Il problema, quindi, non è necessariamente utilizzare gli story points per stimare un'attività. Il problema nasce quando assumiamo che la scala rimanga comparabile dopo aver attraversato i confini tra team e progetti. Il numero continua a sembrare oggettivo, ma il contesto che spiegava quel numero non è più lo stesso.

Più story points non significano automaticamente un cycle time maggiore

Un'altra parte dei dati rende questa differenza ancora più evidente. Abbiamo trovato progetti con una mediana di cinque story points il cui cycle time mediano era significativamente inferiore rispetto a progetti che utilizzavano una mediana di appena uno story point.

In uno dei casi, un progetto con una mediana di cinque punti presentava un cycle time di circa 140,5 ore. Un altro progetto, con una mediana di un punto, superava le 2.000 ore. In un altro confronto, un progetto con una mediana di tre punti presentava circa 120 ore di cycle time, mentre un altro, con una mediana di appena un punto, superava le 4.400 ore.

Questo non significa che un'attività da cinque punti sia naturalmente più veloce di un'attività da un punto. Sarebbe scorretto interpretare il risultato in questo modo. Ciò che mostrano i dati è che i valori assoluti degli story points provenienti da progetti indipendenti non formano una scala temporale comune.

Ogni team costruisce il proprio riferimento di stima. Se quel riferimento viene utilizzato in modo coerente, gli story points possono continuare ad aiutare il team a discutere la complessità relativa e pianificare gli sprint. Ma quando combiniamo più team e trattiamo i valori come se appartenessero tutti alla stessa scala, creiamo un livello di comparabilità che i dati analizzati non supportano.

Perché la story point estimation è difficile da confrontare tra team

Immagina un'organizzazione con tre team di sviluppo. Il Team A completa 80 story points durante uno sprint, il Team B ne completa 45 e il Team C ne completa 110. Quando questi numeri compaiono insieme in una dashboard executive, l'interpretazione più immediata può essere che il Team C consegni di più e il Team B di meno.

Il calcolo è matematicamente corretto, ma la conclusione dipende da un'ipotesi importante: i tre team dovrebbero utilizzare scale di stima equivalenti. Gli story points, però, non sono stati creati per garantire questa equivalenza. Una user story che riceve cinque punti in un team potrebbe riceverne tre oppure otto in un altro, a seconda della complessità tecnica, dell'architettura, dell'esperienza del team, del livello di incertezza e persino delle abitudini di stima sviluppate nel tempo.

Questo è anche uno dei motivi per cui confrontare la velocity tra team può risultare problematico. La velocity in Scrum mostra quanto un determinato team riesce a completare all'interno del proprio riferimento storico, ma non significa automaticamente che quel numero possa essere utilizzato come unità universale di produttività. Quando scale differenti vengono messe una accanto all'altra, la dashboard può creare una sensazione di precisione senza necessariamente produrre un confronto corretto.

Il comportamento osservato nei 204 progetti rafforza esattamente questo punto. Progetti con la stessa mediana di story points possono presentare cycle time radicalmente differenti. Questo significa che i punti possono contenere informazioni utili all'interno di un contesto specifico e, allo stesso tempo, perdere gran parte della loro utilità quando vengono aggregati tra progetti indipendenti.

Perché gli story points possono diventare un problema per il PMO

Gli story points nascono normalmente come tecnica di stima Agile utilizzata dal team, ma in molte organizzazioni finiscono per diventare una delle metriche utilizzate dal management. Un PMO può creare indicatori come story points totali completati, media dei punti per sprint, velocity per team, trend di produttività, capacità e confronti tra progetti differenti.

Tutti questi calcoli possono essere tecnicamente corretti e, nonostante questo, generare interpretazioni sbagliate. Se ogni team ha creato la propria scala relativa, sommare gli story points di più team non trasforma automaticamente quei valori in una metrica standardizzata di portfolio. Un team che completa 100 punti non produce necessariamente il doppio del lavoro, del valore o dei risultati rispetto a uno che ne completa 50.

I numeri mostrano ciò che è accaduto secondo il riferimento di ogni team, ma da soli non sono sufficienti per spiegare perché un progetto stia completando le attività più velocemente, perché un altro stia perdendo prevedibilità o dove venga consumata la capacità. Per rispondere a queste domande dobbiamo analizzare altri segnali generati durante l'esecuzione.

Per me, è esattamente a questo punto che la Project Intelligence deve andare oltre la stima creata all'inizio dell'attività. Il valore originale in story points rimane rilevante, ma deve essere interpretato insieme a ciò che è accaduto successivamente: quanto tempo hanno richiesto normalmente attività simili, quante volte sono state bloccate, se hanno attraversato più sprint, quanto rework o rilavorazione hanno generato e come il loro comportamento si confronta con lo storico del progetto.

Cycle time e altre metriche di software delivery da analizzare oltre agli story points

I dati di un progetto contengono molti altri segnali capaci di spiegare come sta realmente avvenendo la delivery. Il cycle time, o tempo di ciclo, mostra quanto tempo un'attività rimane nel processo prima di essere completata. Il movimento tra sprint permette di osservare quando un'attività continua a essere spostata da uno sprint al successivo. Le dipendenze mostrano quanto un'attività debba attendere altre attività, persone o team prima di poter avanzare, mentre il rework, o rilavorazione, evidenzia quando qualcosa che sembrava completato deve tornare in esecuzione.

Anche i cambi di responsabile sono rilevanti, perché un'attività che passa più volte da una persona a un'altra può comportarsi in modo molto diverso rispetto a un'altra gestita dallo stesso responsabile dall'inizio alla fine. Allo stesso modo, un numero elevato di transizioni nel workflow può indicare che un'attività sta attraversando più fasi, revisioni o cambiamenti rispetto a quanto previsto.

Nessuno di questi indicatori deve necessariamente sostituire completamente gli story points. Il valore sta proprio nell'analizzarli insieme. Una stima mostra ciò che il team riteneva all'inizio. I dati di esecuzione mostrano ciò che è realmente accaduto dopo l'avvio del lavoro.

Considera due attività entrambe stimate con cinque story points. La prima si comporta in modo molto simile a decine di attività equivalenti già completate nello stesso progetto. Il suo cycle time rimane all'interno dell'intervallo storico, non presenta dipendenze rilevanti e attraversa il workflow senza grandi interruzioni. La seconda parte con gli stessi cinque punti, ma viene bloccata, attraversa diversi sprint, cambia responsabile e accumula rilavorazione.

Entrambe continuano a mostrare cinque story points in Jira. Dal punto di vista della delivery, però, non rappresentano più lo stesso rischio.

I dati storici del progetto possono dire più della stima originale

Questa è la parte della gestione dei progetti che mi interessa di più. Invece di chiedermi soltanto quanti story points siano stati assegnati a un'attività, preferisco osservare come si sono comportati in passato lavori simili. Quanto tempo hanno richiesto normalmente? Qual è stata la variazione tra i completamenti più rapidi e quelli più lenti? Le attività con dipendenze hanno mostrato cycle time maggiori? Gli elementi che hanno attraversato più sprint si sono comportati diversamente? La rilavorazione o i cambi di responsabile sono comparsi prima che il tempo di completamento iniziasse ad aumentare?

Lo storico del progetto crea un riferimento basato su ciò che è realmente accaduto. Non elimina la stima iniziale, ma aggiunge contesto e permette di confrontare ciò che ci aspettavamo con ciò che l'esecuzione sta realmente mostrando. Se attività simili vengono normalmente completate entro un determinato intervallo di tempo e una nuova attività inizia ad allontanarsi rapidamente da quel comportamento, abbiamo un segnale molto più utile del solo numero di punti assegnato durante la pianificazione.

In Saint Jude Project Intelligence, utilizziamo i dati del progetto per confrontare le attività attuali con il comportamento storico dello stesso progetto e con attività simili già completate. L'Intelligenza Artificiale aiuta a identificare combinazioni di segnali, deviazioni e pattern ricorrenti che sarebbe difficile individuare osservando soltanto un singolo campo Jira, alcune Jira metrics o un report isolato di sprint.

L'obiettivo non è sostituire il project manager né creare una nuova scala di stima. L'obiettivo è creare un livello di intelligence che aiuti PMO e project leader a capire se le attività attuali continuano a comportarsi in modo coerente con lavori simili, se l'esecuzione ha iniziato ad allontanarsi dal comportamento storico e se le ipotesi utilizzate durante la pianificazione continuano ad avere senso rispetto ai dati disponibili oggi.

Cosa mostrano realmente 204 progetti Jira sugli story points?

Dopo aver analizzato 727.282 issue di Jira e confrontato gli story points con le mediane dei tempi di completamento in 204 progetti software, i dati non supportano l'utilizzo degli story points come metrica universale di delivery dei progetti. Progetti con la stessa mediana di punti possono presentare cycle time radicalmente differenti, mentre progetti che utilizzano mediane più elevate possono, in determinati casi, completare il lavoro molto più velocemente rispetto a progetti che utilizzano valori inferiori.

A causa di questa variazione, l'analisi non fornisce una base per affermazioni come “uno story point equivale a X ore” oppure “un team che completa 100 story points è due volte più produttivo di un team che ne completa 50”. Entrambe le affermazioni richiedono che gli story points funzionino come un'unità standardizzata, e non è questo ciò che osserviamo quando confrontiamo progetti differenti.

Gli story points sono relativi per definizione. Questa caratteristica può renderli utili all'interno del riferimento creato da un team, ma rende anche molto difficile utilizzarli come metrica standardizzata tra team, progetti o strutture di governance aziendale.

Per me, la domanda più utile non è più quante ore dovrebbe richiedere un'attività da cinque punti. La domanda diventa: considerando lo storico di questo progetto e il comportamento di attività simili, cosa sarebbe ragionevole aspettarsi da questa attività oggi?

È in questo momento che una stima inizia a trasformarsi in Project Intelligence. Lo story point rimane un'informazione importante, ma diventa molto più utile quando viene interpretato insieme al comportamento reale della delivery, ai dati storici e agli altri segnali prodotti dal progetto durante l'esecuzione.

Vuoi capire cosa stanno mostrando i dati del tuo Jira?

Gli story points sono soltanto uno dei segnali presenti all'interno di un progetto. Saint Jude analizza i dati dei progetti per identificare pattern legati ai tempi di completamento, ai rischi, alle dipendenze, alla rilavorazione, alla capacità e alla prevedibilità, combinando le stime iniziali con il comportamento storico osservato durante l'esecuzione.

Puoi inviare i dati del tuo progetto e ricevere un'analisi gratuita attraverso il nostro Project Health Checker. L'idea è utilizzare i dati che il progetto già produce per capire non soltanto ciò che dovrebbe accadere, ma come si sta realmente comportando l'esecuzione e quali segnali meritano attenzione prima di trasformarsi in problemi più grandi.

A presto!

Erik Scaranello