Gli Story Point Non Sono Stime di Tempo (E Perché è Importante)
Ogni qualche mese, si ripete la stessa scena. Un product manager entra in una riunione di pianificazione, il team assegna story point a un set di ticket, e poi qualcuno tira fuori un foglio di calcolo convertendo quei punti in ore per poter promettere una data di consegna agli stakeholder.
E così, l'intero scopo degli story point crolla.
Ho visto questo accadere in startup, in scale-up e in aziende che dovrebbero sapere meglio. La causa profonda è sempre la stessa: un fondamentale malinteso su cosa sono destinati a misurare gli story point — e una cultura manageriale che non riesce a resistere a tradurre tutto in una timeline.
Cosa Misurano Davvero gli Story Point
Gli story point sono un'unità di complessità relativa. Confrontano lo sforzo di un pezzo di lavoro con un altro, tenendo conto di complessità, incertezza e rischio — non delle ore dell'orologio.
Quando un team dice "questo è un 5 e quello è un 2," sta dicendo che il primo compito è circa 2,5 volte più complesso del secondo. Non sta dicendo che il primo compito richiede 5 ore o 5 giorni. Il numero è relazionale, non assoluto.
Questa distinzione conta perché:
- Due sviluppatori potrebbero completare la stessa storia a 5 punti in quantità di tempo molto diverse. Uno conosce meglio il codebase. L'altro è più veloce nel debug. La complessità del problema è la stessa per entrambi.
- Una storia a 5 punti in questo sprint potrebbe richiedere più tempo di una storia a 5 punti nel sprint scorso. Cambi di contesto, incidenti di produzione, cambi di team — tutto questo influisce sulla durata ma non sulla complessità.
- La complessità è stimabile; la durata no. Gli ingegneri sono ragionevolmente bravi a confrontare la difficoltà di due compiti. Sono pessimi nel prevedere quante ore qualcosa richiederà. Gli story point si appoggiano alla forza ed evitano la debolezza.
Nel momento in cui inizi a dire "1 punto = mezza giornata," hai abbandonato la stima relativa e sei tornato alle stime di tempo con passi extra.
Perché i Manager Convertono i Punti in Tempo (E il Danno che Causa)
Lo capisco. Se sei un product manager o un CEO, devi rispondere a "quando sarà pronto?" È una domanda legittima. Il problema è la scorciatoia: prendere gli story point e dividerli per una "velocità" per produrre una data.
Ecco cosa succede davvero quando lo fai:
I team iniziano a giocare con i numeri. Se il management tratta i punti come tempo, gli ingegneri imparano a gonfiare le stime per non essere pressati per "impegnarsi" su troppi punti. Quello che era un 3 diventa un 5. Quello che era un 5 diventa un 8. I numeri smettono di significare qualcosa.
La velocità diventa una metrica di performance. Invece di essere uno strumento di pianificazione, la velocità diventa un tabellone segnapunti. I team che "consegnano" più punti vengono premiati. I team iniziano a dividere artificialmente le storie o a gonfiare le stime per sembrare più produttivi. Stai ora misurando la cosa sbagliata e incentivando il comportamento sbagliato.
La fiducia si erode. Gli ingegneri si sentono sorvegliati piuttosto che fidati. Spendono più energia a gestire le aspettative che a risolvere i problemi. La sprint planning cessa di essere una conversazione collaborativa su cosa è realistico e diventa una negoziazione dove entrambe le parti si posizionano.
La precisione delle stime peggiora, non migliora. L'ironia è crudele: più premi per stime di tempo precise, meno affidabili diventano le tue stime. La pressione introduce bias. Il bias distrugge il segnale.
Alternative che Funzionano Davvero
Se gli story point vengono usati male nel tuo team, hai delle opzioni. Alcuni team se la cavano meglio passando completamente a un approccio diverso.
Dimensionamento con T-Shirt
Invece dei numeri, usa S/M/L/XL. È deliberatamente impreciso, che è il punto. Forza conversazioni sulla dimensione relativa senza l'illusione di precisione matematica. Un product owner può guardare una roadmap di medie e grandi e avere un'idea approssimativa dell'estensione senza che nessuno pretenda che una L equivale esattamente a 3,5 giorni.
Il Movimento No-Estimates
Questo è più radicale: smetti di stimare le storie individuali del tutto. Invece, concentrati sulla suddivisione del lavoro in pezzi piccoli e di dimensioni simili e misura il throughput. Se il tuo team completa in media 12 elementi per sprint e il backlog ha 36 elementi di dimensioni simili, puoi prevedere "circa 3 sprint" senza mai assegnare un numero a una storia individuale.
Funziona meglio quando hai disciplina nella scomposizione delle storie. Se alcune storie sono minuscole e altre sono enormi, la previsione basata sul throughput crolla.
Previsione per Tempo di Ciclo
Questo è il mio approccio preferito per i team che hanno almeno qualche mese di dati storici. Invece di stimare in avanti, guardi indietro per vedere quanto tempo impiega davvero il lavoro.
Il tempo di ciclo è la durata da quando il lavoro inizia a quando è completato. Se traccia questo per storia o ticket, puoi calcolare i percentili:
- "L'85% delle nostre storie si completa entro 7 giorni."
- "Il 50% si completa entro 3 giorni."
Ora quando qualcuno chiede "quando sarà pronto?" dai una risposta probabilistica: "In base alla nostra storia, c'è un 85% di probabilità che sia pronto entro 7 giorni lavorativi." Questo è più onesto, più difendibile e più utile di qualsiasi stima basata sui punti.
Strumenti come Jira, Linear e Shortcut possono generare dati sul tempo di ciclo. Non hai bisogno di niente di sofisticato — un foglio di calcolo che tiene traccia della data di inizio e di completamento per storia ti darà l'80% del valore.
Quando la Stima Aggiunge Valore
Non sono contro la stima. La stima è utile quando serve a uno scopo chiaro:
- Per delimitare grandi iniziative. Quando devi decidere tra due progetti che potrebbero richiedere 3 mesi vs. 9 mesi, la stima approssimativa aiuta ad allocare risorse e definire le aspettative. Il dimensionamento con t-shirt o lo story mapping funzionano bene qui.
- Per identificare gli sconosciuti. Se il team non riesce ad accordarsi su se qualcosa è un 3 o un 13, quel disaccordo è il valore. Fa emergere supposizioni diverse, requisiti mancanti e complessità nascosta. La conversazione attorno alla stima è più preziosa del numero.
- Per la pianificazione della capacità. Sapere approssimativamente quanto lavoro rientra in uno sprint aiuta i team a evitare il sovra-impegno. Ma questo funziona solo se proteggi le stime dall'essere trasformate in armi come scadenze.
Quando la Stima è Puro Spreco
La stima non aggiunge valore quando:
- Ogni storia ha all'incirca la stessa dimensione. Se il tuo team è diventato bravo a suddividere il lavoro in piccoli pezzi, le stime sono ridondanti. Conta solo le storie.
- Le stime non alimentano alcuna decisione. Se nessuno usa le stime per prendere una decisione di pianificazione, stai spendendo 30 minuti per sprint in un rituale che non produce niente.
- Le stime vengono usate per incolpare, non per pianificare. "Hai detto che era un 3 e ha richiesto una settimana." Se quella frase è mai stata pronunciata nel tuo team, il tuo processo di stima sta facendo più danni che bene.
L'Obiettivo Reale: Prevedibilità, Non Precisione
Ecco cosa la maggior parte delle persone perde: l'obiettivo di qualsiasi pratica di stima è la prevedibilità, non la precisione. Non hai bisogno di sapere che la Funzionalità X richiederà esattamente 14 giorni. Hai bisogno di sapere che il tuo team può consegnare in modo affidabile un set di funzionalità entro un trimestre. Questo è un problema diverso, e si risolve con metriche di flusso, non con ipotesi migliori.
Tieni traccia del tempo di ciclo. Misura il throughput. Monitora i limiti di lavoro in corso. Questi sono indicatori ritardati che riflettono la realtà, non indicatori anticipati che riflettono la speranza.
I team con cui ho lavorato che hanno la più alta prevedibilità di consegna non sono quelli con i rituali di stima più sofisticati. Sono quelli che mantengono il lavoro piccolo, limitano il WIP e usano i dati storici per prevedere. Non è necessario il planning poker.
In Conectia, gli ingegneri senior che integriamo nei tuoi team capiscono questo. Hanno lavorato in abbastanza team da sapere che il teatro delle stime spreca il tempo di tutti, e portano abitudini pratiche — PR piccole, perimetro chiaro, throughput coerente — che rendono la tua consegna prevedibile senza trasformare la sprint planning in una negoziazione. Questo è quello che fanno gli ingegneri esperti: fanno funzionare il processo, non solo il codice.
Stanco del teatro delle stime che rallenta il tuo team? Parla con un CTO — i nostri ingegneri senior LATAM portano le abitudini di consegna che rendono la prevedibilità un sottoprodotto, non una battaglia.
