La Morte degli Story Point (E Cosa Viene Dopo)

Il culto cargo di Fibonacci

Gli story point sono diventati il culto cargo dell'ingegneria moderna.

I team assegnano religiosamente numeri di Fibonacci ai ticket. Discutono se un 3 sia davvero un 5. Calcolano la velocity con precisione decimale. Proiettano sprint futuri basandosi su medie storiche. E poi si chiedono perché le loro previsioni assomiglino ad arte astratta.

Ecco una verità scomoda: gli story point sono stati progettati per un mondo che non esiste più.

La premessa originale era semplice: gli sviluppatori lavorano a velocità relativamente costanti, quindi misurare la complessità relativa (un 5 è circa il doppio di un 3) dovrebbe produrre una velocity prevedibile nel tempo. Stabilisci una baseline e puoi fare previsioni con ragionevole accuratezza.

Quella premessa ora è infranta.

Perché gli story point stanno morendo?

Gli story point presuppongono un'unità stabile: lo stesso team, che lavora allo stesso modo, a una velocità più o meno costante. L'assistenza AI ha infranto questo presupposto in tre modi: le stime ora variano enormemente per task, la velocity non prevede più la consegna e le baseline storiche non si trasferiscono più.

Il problema della variabilità AI

Quando lo stesso sviluppatore può essere 10 volte più veloce il lunedì (con Copilot, una specifica chiara e un codebase familiare) rispetto al martedì (alle prese con un sistema legacy, il debug di un'allucinazione AI e il cambio di contesto tra tre progetti)—cosa significa esattamente una "storia da 5 punti"?

Non significa nulla. L'unità di misura è diventata variabile.

Considera un esempio reale: uno sviluppatore stima una funzionalità CRUD a 5 punti basandosi sulla velocity storica. Con l'assistenza AI, la completa in 2 ore. La storia successiva da 5 punti riguarda il debug di una race condition in codice legacy, dove l'AI è inutile, e richiede 3 giorni.

Entrambe erano "5 punti". Una ha richiesto 2 ore, l'altra 24. Il tuo grafico della velocity ora contiene punti dati che variano di 12 volte per la stessa complessità stimata.

Il problema della velocity priva di significato

Il report DORA 2024 ha rilevato che i team che adottano assistenti di codifica AI hanno visto il throughput di consegna diminuire dell'1,5% e la stabilità di consegna diminuire del 7,2%¹: più attività, meno valore consegnato. La velocity misura l'attività piuttosto che i risultati, motivo per cui i team con alta velocity spesso consegnano meno valore rispetto ai team con velocity moderata.

Quando l'AI gonfia le metriche di attività (più commit, più PR, più storie "completate"), la velocity diventa puro rumore. Il numero sale, ma nessuno sa cosa significhi.

Il problema della baseline storica

La stima degli story point si basa sulla calibrazione: "L'ultimo sprint abbiamo completato 40 punti, quindi impegniamoci per 40 questo sprint". Ma cosa succede quando:

• Metà del team ha appena adottato assistenti AI (la velocity potrebbe aumentare)?
• Il codebase su cui stai lavorando non è familiare all'AI (la velocity potrebbe diminuire)?
• Il tuo miglior estimatore se n'è andato portandosi via la sua calibrazione?

Le baseline storiche presuppongono coerenza. L'AI ha distrutto quel presupposto.

Cosa sostituisce gli story point?

La morte degli story point non significa la morte della stima. Tre approcci funzionano nell'era dell'AI: esperimenti time-boxed, impegni sui risultati e ri-stima continua.

Approccio 1: Esperimenti time-boxed

Invece di stimare quanto tempo richiederà qualcosa, impegnati su cosa tenterai entro un time box fisso.

Il vecchio modo: "Questa funzionalità vale 8 punti, che storicamente significa ~4 giorni."

Il nuovo modo: "Dedicheremo 2 giorni all'esplorazione di questa funzionalità. Alla fine, sapremo se possiamo consegnarla o se serve più tempo."

Questo approccio riconosce l'incertezza in anticipo. Non stai fingendo di prevedere l'imprevedibile—ti stai impegnando a imparare rapidamente.

Approccio 2: Impegni sui risultati

Invece di stimare lo sforzo, impegnati su un risultato entro una data—e lascia che il team capisca come arrivarci.

Il vecchio modo: "Questa epic vale 40 punti su 8 storie, quindi richiederà 2 sprint."

Il nuovo modo: "Consegneremo l'autenticazione utente entro venerdì. Ecco la versione minimale praticabile, ecco gli obiettivi estesi ed ecco cosa taglieremo se necessario."

Questo approccio si concentra su ciò che conta (risultati) piuttosto che su proxy (sforzo). Crea allineamento sulle priorità e fa emergere i rischi presto: "Se non riusciamo a far funzionare OAuth entro mercoledì, consegneremo solo con email/password."

Approccio 3: Ri-stima continua

Invece di stimare una volta alla pianificazione dello sprint e non rivisitare mai, aggiorna le stime man mano che impari.

Il vecchio modo: "Abbiamo stimato 5 punti alla pianificazione, quindi quella è la stima."

Il nuovo modo: "Abbiamo stimato 5 punti lunedì. Entro mercoledì sappiamo che in realtà è un 8. Questa è un'informazione preziosa—aggiorniamo i nostri impegni."

Questo approccio tratta la stima come uno strumento per una conversazione continua piuttosto che una previsione una tantum. La stima evolve man mano che la conoscenza cresce.

Come evolve Planning Poker

Abbiamo costruito il nostro strumento di planning poker per supportare questi approcci—non perché pensiamo che la stima tradizionale sia sempre sbagliata, ma perché i team hanno bisogno di flessibilità.

Per la stima tradizionale

Sì, puoi ancora assegnare punti Fibonacci. Alcuni team e alcuni tipi di lavoro beneficiano ancora della stima relativa. Codebase stabili, team esperti, domini ben compresi—gli story point possono funzionare qui.

Ma abbiamo aggiunto salvaguardie:

• Rilevamento anomalie: Le metriche dello sprint passano attraverso il rilevamento anomalie z-score, quindi quando la velocity oscilla fuori dal suo range normale lo vedi segnalato invece che sepolto in una media.
• Tracciamento pianificato-versus-completato: Le metriche dello sprint confrontano ciò a cui ti sei impegnato con ciò che è stato effettivamente consegnato, quindi la deriva della stima emerge sprint dopo sprint invece che al rendiconto trimestrale.
• Trend dei risultati, non tracciamento degli strumenti: Non tracciamo mai chi ha usato l'AI su cosa. Il confronto sprint-dopo-sprint mostra se le tue stime stanno diventando più o meno affidabili, qualunque sia la causa.

Per esperimenti time-boxed

Invece di assegnare punti, stima in time box. La scala Tempo (Ore) va da 1 ora a 40, e le scale personalizzate ti permettono di definire i tuoi checkpoint:

• Spike di 2 ore
• Esplorazione di mezza giornata
• Prototipo di 1 giorno

Alla fine del time box, il team risponde a una semplice domanda: "Possiamo consegnare questo, o serve più tempo?" Questo crea checkpoint naturali senza falsa precisione.

Per impegni sui risultati

Gli impegni sui risultati non richiedono strumenti speciali. Definisci il risultato, stabilisci una data target e scomponi in milestone con checkpoint go/no-go. Dove gli strumenti aiutano è dopo: il tracciamento degli action item e gli health score mostrano se l'impegno è stato consegnato e ha tenuto.

La conversazione è il punto

Ecco cosa la maggior parte dei team non coglie riguardo alla stima: la stima in sé non conta. Conta la conversazione.

Quando il tuo team discute se qualcosa sia un 3 o un 5, il valore non sta nel raggiungere il numero "corretto". Il valore sta nel far emergere presupposti diversi:

• "Penso sia un 3 perché possiamo riutilizzare il modulo di autenticazione esistente."
• "Penso sia un 5 perché il modulo di autenticazione esistente non gestisce i nostri nuovi requisiti."

Quella conversazione ha rivelato un rischio. La stima è quasi irrilevante; la comprensione condivisa è tutto.

Questo è il motivo per cui le cerimonie di stima rimangono preziose anche quando le stime stesse sono imprecise. L'obiettivo non è la previsione. L'obiettivo è l'allineamento.

Comunicare il cambiamento

Se sei convinto che gli story point tradizionali non funzionino, dovrai comunicarlo agli stakeholder che si aspettano "dashboard di velocity". Ecco come:

Per la leadership tecnica

Inquadralo in termini di prevedibilità, non di processo. I leader si preoccupano di sapere quando le cose verranno rilasciate. Spiega che la velocity è diventata inaffidabile (mostra la varianza) e che stai adottando pratiche che miglioreranno effettivamente la prevedibilità.

Mostra, non dire. Esegui un esperimento parallelo: traccia la velocity tradizionale E gli impegni basati sui risultati per due mesi. Lascia che siano i dati a parlare.

Per i partner di prodotto

Concentrati su ciò che gli interessa: le date di rilascio. I product manager non si preoccupano degli story point—si preoccupano di sapere quando le funzionalità saranno pronte. Gli impegni basati sui risultati forniscono loro informazioni migliori: "Rilasceremo entro venerdì" è più utile di "Abbiamo completato 40 punti."

Rendilo una questione di emersione dei rischi. La ri-stima continua fa emergere i rischi prima. È ciò di cui il prodotto ha bisogno: un avviso tempestivo, non una falsa sicurezza.

Per il team

Riconosci la disfunzione. Se gli story point sono diventati un rituale vuoto, il team lo sa. Ammetterlo crea fiducia.

Rendilo inizialmente opzionale. Lascia che il team sperimenti alternative su alcune storie prima di impegnarsi in una transizione completa.

Il futuro della stima

Ecco dove siamo diretti:

Breve termine: La stima diventa adattiva. I team usano approcci diversi per tipi di lavoro diversi: story point per lavoro stabile e ben compreso; time-box per l'esplorazione; impegni basati sui risultati per funzionalità ad alta priorità.

Medio termine: L'AI assiste con la stima stessa. Basandosi su pattern storici, analisi della complessità del codebase e lavoro passato simile, l'AI può suggerire stime—non come verità, ma come input per la conversazione.

Lungo termine: La stima diventa meno necessaria. Man mano che i cicli di deployment si comprimono e i feedback loop si stringono, la necessità di previsione anticipata diminuisce. Saprai se qualcosa è difficile lavorandoci per qualche ora, non discutendo punti in una riunione di pianificazione.

Gli story point ci hanno servito bene per due decenni. Erano lo strumento giusto per il loro tempo. Ma le condizioni che li rendevano utili sono cambiate radicalmente, e le nostre pratiche devono cambiare con esse.

Cosa significa per il tuo team

Se stai sperimentando una disfunzione degli story point, non sei solo. Ecco da dove iniziare:

1. Misura la varianza della tua velocity. Se fluttua più del 25% da sprint a sprint, le tue stime non sono predittive; sono rumore.

2. Prova un'alternativa. Scegli alcune storie nel prossimo sprint e stimale con time-box invece che con punti. Vedi come ti senti.

3. Concentrati sui risultati. Durante la pianificazione, chiedi "Cosa vogliamo che sia vero entro la fine dello sprint?" piuttosto che "Quanti punti possiamo completare?"

4. Abbraccia l'incertezza. La risposta onesta a "Quanto tempo ci vorrà?" è spesso "Non lo so ancora—lasciami provare per un giorno e ti dirò di più."

L'obiettivo non è mai stato assegnare il numero giusto. L'obiettivo era rilasciare software di valore. Se le tue pratiche di stima stanno ostacolando quell'obiettivo, è tempo che evolvano.

Fonti