Story Points nello sviluppo — cosa sono, scale di valutazione e applicazione

Cosa sono gli story points?

Gli story points sono una metrica della complessità dei compiti utilizzata in Scrum e in altre metodologie agili. Il team valuta ogni compito non in ore, ma in unità relative: “questo compito è due volte più complesso del riferimento.” Questo approccio livella la differenza di velocità tra i diversi sviluppatori e si concentra sulla complessità.

Origine del termine

Il concetto di story points è emerso all'inizio degli anni 2000 con la popolarizzazione di Scrum. Uno dei primi a descrivere il metodo fu Ron Jeffries nell'ambito dell'Extreme Programming (XP). L'idea era di allontanarsi dalla stima in “ore-uomo,” che è sempre imprecisa, verso una complessità relativa che il team determina collettivamente. Oggi, gli story points sono lo standard del settore per i team agili.

Fattori considerati negli story points

Quando si stima in story points, il team considera tre fattori: volume di lavoro (quantità di codice, schermate, logica), complessità (sfide tecniche, nuove tecnologie) e incertezza (requisiti poco chiari, rischi). Uno story point può significare “un compito semplice senza rischi,” mentre 8 può significare “un compito complesso con alta incertezza.”

Scale di story points: come scegliere

La scelta della scala di story points influisce sulla precisione della stima e sulla comodità di pianificazione. La scala più popolare è la sequenza di Fibonacci, ma esistono alternative.

Perché Fibonacci? La psicologia della scala

La sequenza di Fibonacci non è stata scelta a caso. La differenza tra 1 e 2 è minima (50%), mentre tra 13 e 21 è significativa (62%). Questo riflette la realtà: i compiti piccoli vengono stimati più accuratamente, i compiti grandi con maggiore dispersione. Quando un compito viene stimato a 21 story points, il team capisce: “non sappiamo quanto tempo ci vorrà, ma è decisamente più di 13.” La scala di Fibonacci previene la falsa precisione.

Il compito di riferimento — base della scala

Affinché la scala funzioni, il team concorda su un riferimento: “il compito X è 1 story point.” Di solito viene scelto un compito semplice e ben noto come riferimento: “aggiungere un campo di testo a una schermata” o “correggere un errore di battitura.” Tutti gli altri compiti vengono stimati rispetto al riferimento. Senza un riferimento, gli story points perdono il loro significato — ognuno intende l'unità in modo diverso.

Velocity del team e previsioni

Velocity è il numero medio di story points che un team completa per sprint. Questa è una metrica chiave per prevedere le tempistiche del progetto.

Come viene calcolata la velocity

Velocity viene calcolata in base ai compiti completati: si sommano gli story points di tutti i compiti che il team è riuscito a portare a termine (la definizione di fatto è soddisfatta). I compiti non completati non vengono conteggiati. Per precisione, si prende la media degli ultimi 3–5 sprint. Ad esempio, se un team ha completato 20, 22, 18 e 24 story points negli ultimi 4 sprint, velocity = 21 sp.

Previsioni attraverso la velocity

Conoscendo la velocity e il volume totale del backlog in story points, è possibile prevedere il numero di sprint fino al rilascio. Ad esempio, se il backlog ha 210 story points e la velocity = 21, serviranno 10 sprint. Questa è una previsione approssimativa che viene perfezionata con l'avanzare del lavoro. Importante: la velocity è una media, non un impegno. Pianificate in base al limite inferiore (18 sp), non alla media.

Come aumentare la velocity

Velocity non può essere aumentata per decreto — è un sintomo della salute dei processi. Una crescita sostenibile della velocity si ottiene attraverso: riduzione del debito tecnico, miglioramento dei processi di revisione del codice, riduzione dei cambi di contesto, automazione dei test e CI/CD. Importante: la velocity di team diversi non può essere confrontata — ogni team definisce gli story points a modo proprio.

Story points vs ore: cosa e quando usare

Story points e ore hanno scopi diversi, e la scelta tra di essi dipende dal contesto. I team esperti utilizzano entrambi gli approcci per compiti diversi.

Quando gli story points funzionano meglio

Gli story points sono indispensabili per la pianificazione degli sprint: non dipendono da chi eseguirà il compito. Un junior può fare 2 sp al giorno, un senior 4 sp, ma la stima del compito rimane 2 sp per entrambi. Gli story points consentono di tracciare la produttività del team senza confrontare gli sviluppatori. Questo riduce la pressione politica e migliora l'atmosfera del team.

Quando le ore sono necessarie

Le ore sono necessarie per gli impegni esterni: contratti, budget, report per il cliente. Il cliente vuole sapere non “8 story points” ma “3 settimane.” Per convertire gli story points in ore, utilizzate il tasso di conversione storico: il team sa che 1 sp equivale a circa 4 ore di lavoro. La conversione dovrebbe essere trasparente e basata sui dati, non su supposizioni.

Approccio combinato

Molti team utilizzano un approccio combinato: i compiti vengono stimati in story points per la pianificazione dello sprint, e poi il manager li converte in ore/giorni per i report esterni. È importante non mescolare i due sistemi in un unico processo: o si stima in story points e si ricava il tempo dalla velocity, o si stima direttamente in ore.

Errori comuni con gli story points

L'implementazione degli story points è spesso accompagnata da errori che annullano i vantaggi della stima relativa. Ecco i più comuni.

Legare gli story points al tempo

L'errore più comune — il team concorda: “1 sp = 4 ore.” In questo caso, gli story points perdono il loro significato e si trasformano in ore con un nome diverso. Gli story points dovrebbero essere relativi, non legati al tempo. Se il compito A è due volte più complesso del compito B, riceve 2 sp, indipendentemente da quante ore richiederà.

Stima post-factum

Quando un compito viene stimato dopo essere stato completato — non è una stima, è una constatazione. Gli story points dovrebbero essere assegnati prima dell'inizio del lavoro, nel momento di massima incertezza. La stima post-factum distorce la velocity e non apporta benefici alla pianificazione. Inoltre, crea una falsa sensazione di precisione.

Confrontare la velocity tra team

Confrontare la velocity del team A e del team B è un esercizio senza senso. Ogni team definisce il riferimento e la scala in modo diverso. Per un team, 1 sp è un compito semplice di un'ora, per un altro è un compito di un giorno. Si può solo confrontare la velocity dello stesso team nel tempo: se sta crescendo o diminuendo.

Scala incoerente

Quando compiti diversi con la stessa complessità ricevono story points diversi, e quelli più complessi ne ricevono meno, la scala si rompe. Il team dovrebbe calibrare regolarmente la scala: ogni 3–6 sprint, rivedere retrospettivamente quanto le stime corrispondevano alla complessità reale. Questo migliora la coerenza delle stime.