Story points agili: una guida pratica per stimare senza le ore

11 giugno 2026 — Kai Petersen

Gli story points sono un’unità relativa che i team agili usano per stimare il lavoro. Invece di dire «questo task richiederà sei ore», il team dice «questo task è un 5 — grande più o meno quanto quella cosa che abbiamo fatto lo sprint scorso». L’idea è tutta qui. Tutto il resto — le scale Fibonacci, i grafici di velocity, le sessioni di planning poker — è costruito su questo unico passaggio dal tempo assoluto alla dimensione relativa.

Questa guida spiega cosa misurano gli story points, perché deliberatamente non sono ore, quali scale usano i team, come condurre concretamente una sessione di story pointing e come i numeri finiscono in Jira. Alla fine c’è una cheat sheet da tenere accanto al backlog.

Cosa misurano davvero gli story points

Uno story point raggruppa tre cose in un solo numero:

Complessità — quante parti in movimento ha il lavoro e quanto ragionamento richiede
Incertezza — quanto del lavoro è sconosciuto o dipende da fattori esterni al team
Sforzo — la pura quantità di lavoro, indipendentemente da chi lo fa

La proprietà chiave è che gli story points sono relativi. Una story da 4 punti è circa il doppio di una da 2 punti — per il tuo team, sulla vostra codebase, con i vostri strumenti. Fuori da quel contesto il numero non significa nulla, ed è così per scelta.

In pratica, i team ancorano la scala con una story di riferimento: scegliete un lavoro piccolo e ben compreso che tutti ricordano — ad esempio «aggiungere un campo al modulo di registrazione» — e chiamatelo un 2. Da lì in poi, ogni stima è un confronto: più grande o più piccolo del riferimento, e di quanto circa?

Due persone con livelli di esperienza molto diversi possono concordare che il task A è circa il doppio del task B, anche se avrebbero bisogno di tempi molto diversi per farlo. Per questo la stima relativa tende a produrre meno discussioni delle stime in tempo — alla domanda comparativa si risponde più onestamente che a «quante ore servono a te?».

Perché gli story points non sono ore

L’errore più comune con gli story points è riconvertirli silenziosamente in tempo. Di solito si presenta come una tabella di conversione che qualcuno appende nel wiki: 1 punto = 4 ore, 2 punti = 1 giorno, e così via.

Nel momento in cui quella tabella esiste, non hai più story points — hai ore con passaggi in più. Tutti i problemi che gli story points dovevano evitare ritornano: le persone si ancorano alla propria velocità invece che alla dimensione del lavoro, le stime vengono trattate come impegni vincolanti, e le discussioni passano da «quanto è grande?» a «perché ci è voluto più di quanto diceva la tabella?».

Il collegamento con il tempo esiste, ma passa attraverso la velocity: dopo qualche sprint sai che il tuo team completa, diciamo, 25–30 punti per sprint. Quello è il tuo numero di pianificazione. Converte i punti in tempo a livello di team, sulla base di dati osservati — non per singolo task, e non secondo una tabella inventata.

Per essere onesti: la stima basata sul tempo non è sbagliata. Per team che fatturano ai clienti, fanno supporto o hanno scadenze esterne rigide, le ore possono essere l’unità più onesta. Abbiamo confrontato i due approcci in tempo vs. story points se vuoi l’analisi completa. Gli story points si guadagnano il loro posto nel lavoro di prodotto iterativo, dove il dimensionamento relativo più la velocity misurata battono le stime di tempo per task.

Le scale di story points: Fibonacci, taglie di maglietta, valori personalizzati

La maggior parte dei team usa una sequenza di Fibonacci modificata: 1, 2, 3, 5, 8, 13, 21. Gli intervalli crescenti sono il punto — sulla differenza tra 1 e 2 un team può discutere in modo sensato, mentre la differenza tra 20 e 21 è falsa precisione. Il lavoro più grande porta più incertezza, quindi la scala diventa più grossolana man mano che i numeri crescono. Il ragionamento completo è in perché il planning poker usa la serie di Fibonacci.

Due alternative comuni:

Taglie di maglietta (XS, S, M, L, XL) — utili per il dimensionamento iniziale a livello di roadmap, dove i numeri suggerirebbero una precisione che nessuno ha. Meno utili per la pianificazione dello sprint, perché le lettere non si sommano in una velocity.
Valori personalizzati — alcuni team limitano la scala a 8 («tutto ciò che è più grande si divide»), altri aggiungono una carta tazza di caffè per «mi serve una pausa». La maggior parte degli strumenti di planning poker, il nostro incluso, ti lascia definire i tuoi valori delle carte.

Quale scala scegli conta meno dell’usarla con coerenza. La velocity funziona solo se un 5 di questo sprint significa la stessa cosa di un 5 dello sprint scorso.

Come condurre una sessione di story pointing

Lo story pointing funziona meglio come esercizio di gruppo strutturato, e il formato standard è il planning poker. Il flusso:

Leggere la story. Il product owner o il facilitatore legge la user story e risponde alle domande di chiarimento. Ancora niente numeri.
Tutti stimano contemporaneamente. Ogni membro del team sceglie una carta in privato. La rivelazione simultanea è il meccanismo centrale — impedisce l’ancoraggio, cioè che il primo numero detto ad alta voce trascini tutti gli altri verso di sé.
Rivelare e confrontare. Se le stime concordano, si annota il numero e si va avanti. Passare dieci minuti a discutere se qualcosa è un 3 o un 5 è di solito tempo sprecato.
Discutere i valori anomali. Se una persona dice 2 e un’altra 13, quel divario è informazione. Di solito una delle due sa qualcosa che l’altra non sa — una dipendenza nascosta, una funzione di supporto già esistente, un requisito normativo. Lascia che gli estremi si spieghino per primi, poi si rivota.
Rivotare finché non si è abbastanza vicini. Due round sono la norma. Se una story non converge dopo tre, di solito è troppo vaga o troppo grande — dividila o rimandala al refinement.

Qualche numero pratico da come vediamo i team usare il nostro strumento: i team da 3–15 persone sono il caso tipico, con 10–20 story per sessione e ben meno di due ore in totale. Oltre, la qualità delle stime cala più in fretta del backlog.

Il planning poker è uno dei vari formati di stima — l’affinity estimation e altri scalano meglio per backlog molto grandi — ma per la stima a livello di sprint con un singolo team, è lo standard per una buona ragione.

Gli story points in Jira

Se il tuo team lavora in Jira, gli story points vivono in un campo dedicato, e i report di velocity e burndown di Jira li aggregano automaticamente una volta che il campo è compilato. Tre cose da sapere:

Il campo potrebbe dover essere attivato. Jira supporta un campo «Story Points» sulle issue, ma a seconda del template devi prima aggiungerlo alle tue schermate.
Jira memorizza le stime; non le produce. Non c’è un meccanismo integrato di votazione o di rivelazione simultanea — decidere quale numero va nel campo avviene fuori dalle funzionalità di base di Jira, tramite un plugin a pagamento del Marketplace oppure uno strumento autonomo in una seconda scheda del browser. Abbiamo confrontato onestamente entrambi i flussi di lavoro — inclusi i casi in cui il plugin è la scelta migliore — in planning poker per Jira senza plugin.
Jira accetta qualsiasi numero; il tuo team non dovrebbe. Il campo accetta decimali arbitrari. Restate comunque sulla scala concordata — un backlog con dei 3,5 e dei 6 significa che qualcuno sta convertendo in tempo a mente.

La versione breve: gli story points in Jira sono un output. La stima in sé — la discussione, la rivelazione, la rivotazione — è l’argomento di tutto questo articolo, e avviene nella conversazione, non nel campo.

Cheat sheet degli story points

Una tabella di riferimento per la scala Fibonacci modificata. Le descrizioni sono un punto di partenza — le story di riferimento del tuo team le affineranno col tempo.

Punti	Significato approssimativo	Azione tipica
1	Banale. Ben compreso, modifica minuscola.	Farlo e basta.
2	Piccolo. Terreno noto, nessuna sorpresa attesa.	Buona dimensione per la story di riferimento.
3	Medio. Richiede un po’ di ragionamento, incognite minori.	Ordinaria amministrazione di sprint.
5	Grande. Diverse parti in movimento o una vera incognita.	Va bene, ma verificate che stia in uno sprint.
8	Molto grande. Più incognite, tocca più aree.	Valutare di dividerla.
13	Enorme. Incertezza significativa.	Dividerla, salvo una ragione forte per non farlo.
21	Troppo grande per una stima onesta.	Dividere sempre. È un’epic travestita da story.

Errori comuni (e limiti onesti)

Gli errori che vediamo più spesso:

Convertire i punti in ore per task. Trattato sopra — cancella silenziosamente il beneficio dell’intero sistema.
Fare la media invece di discutere. Se i voti sono 2, 3, 5 e 13, la risposta non è 5,75. Il 13 ha un motivo; trovatelo.
Confrontare la velocity tra team. I 30 punti del team A e i 30 punti del team B non hanno nulla a che fare tra loro. Il confronto di velocity tra team punisce chi stima onestamente e premia l’inflazione.
Usare i punti come metrica di performance. Nel momento in cui i «punti consegnati» compaiono nelle valutazioni delle prestazioni, le stime si gonfiano e i dati perdono valore. La velocity è un input di pianificazione, non un voto di produttività.

E i limiti onesti: gli story points non sistemano requisiti poco chiari, un team instabile o un product owner che rimescola le priorità a metà sprint — rendono solo quei problemi visibili più in fretta, il che è scomodo ma utile. Per team molto piccoli (due o tre persone) che condividono già tutto il contesto, il pointing formale può essere più cerimonia di quanto valga; un rapido «piccolo, medio o spaventoso?» a volte fa lo stesso lavoro. E i dati di velocity dei primi sprint saranno rumorosi — è normale, non un segno che state sbagliando.

FAQ

Cosa sono gli story points nell’agile? Un’unità relativa per stimare il lavoro. Invece di stimare il tempo, il team valuta la dimensione di ogni story — complessità, incertezza e sforzo combinati — confrontandola con lavoro già fatto. I numeri sono specifici del team e hanno senso solo al suo interno.

Quante ore è uno story point? Non esiste una conversione fissa, di proposito. Il legame tra punti e tempo emerge a livello di team attraverso la velocity — i punti che il tuo team completa davvero per sprint, misurati su più sprint. Qualsiasi tabella di conversione per task ritrasforma gli story points in ore e ne elimina il beneficio.

Quale scala dovremmo usare per gli story points? La sequenza di Fibonacci modificata (1, 2, 3, 5, 8, 13, 21) è la scelta più comune, perché gli intervalli crescenti rispecchiano l’incertezza crescente del lavoro più grande. Le taglie di maglietta funzionano per il dimensionamento approssimativo della roadmap. La coerenza conta più della scala specifica.

Gli story points funzionano fuori dai team software? Sì — il meccanismo è generico. Qualsiasi team che stima lavoro con incertezza intrinseca (campagne di marketing, produzione di contenuti, prototipazione hardware) può dimensionare in modo relativo e tracciare una velocity. Il trucco della story di riferimento funziona allo stesso modo.

Se vuoi provare lo story pointing con il tuo team, apri una stanza di planning poker gratuita — niente registrazione, condividi il link, iniziate a votare. La versione gratuita mostra annunci; Premium (40 USD/anno per tutto il team) li rimuove. Una sessione di sprint planning basta per capire se la stima relativa fa per il tuo team.