Story point contro #NoEstimates: il nostro verdetto
Nessuna delle due posizioni prevale in modo assoluto. Si effettua una stima per raggiungere una comprensione condivisa e individuare eventuali disaccordi; non si effettua una stima per prevedere una data, ma per formulare una previsione basata sulla produttività. Esaminiamo in modo critico gli story point, il movimento #NoEstimates e l’ideatore che ha rinnegato i punti, per poi trarre le nostre conclusioni.
Nessuna delle due parti prevale in modo definitivo. Si effettui una stima per costruire una comprensione condivisa e individuare eventuali disaccordi; non si effettui una stima per prevedere una data — si ricorra invece a una previsione basata sulla produttività. Il numero in sé è praticamente privo di valore. È la conversazione che lo ha generato a costituire il vero valore.
La discussione viene presentata come una scelta binaria — punti o niente — ma in realtà non lo è. Entrambe le parti hanno ragione su qualcosa e entrambe possono contare sul sostegno di un’autorità di grande peso. La posizione più utile è quella che prende in considerazione l’argomentazione più forte di ciascuna parte e ne mantiene solo le parti che reggono alla prova di un vero e proprio sprint.
I vantaggi degli story point
L’argomentazione di Mike Cohn, la posizione definitiva a favore dei punti, non ha mai riguardato realmente il numero in sé. Il punto è che l’atto stesso di stimare in termini relativi costringe il team a discutere della complessità, a portare alla luce presupposti nascosti e a concordare su ciò che una storia comporta effettivamente prima che qualcuno scriva il codice. I punti consentono inoltre di aggirare una specifica patologia: se si stima in giorni, ogni cifra diventa oggetto di contrattazione; se si stima in un’unità astratta, la contrattazione non ha alcun punto di riferimento. Il problema è che tutti colgono il sottinteso — «non stiamo stimando il tempo, ma solo la complessità, in modo da poter pianificare lo sprint, che dura due settimane» — e l’astrazione protegge il team solo finché nessuno la riconverte direttamente in una data.
Steve McConnell rappresenta il rigoroso contrappeso alla corrente contraria alla stima. Egli sostiene che la causa principale delle stime errate sia solitamente la mancanza di competenza nella stima, non la stima in sé — e che i professionisti seri distinguano tre elementi che il dibattito continua a confondere: la stima (ciò che è probabile), l’obiettivo (ciò che l’azienda desidera) e l’impegno (ciò che il team promette). Se le si confonde, è ovvio che la stima sembri fallimentare. Se le si mantiene distinte, invece, funziona davvero.
Le ragioni a favore di #NoEstimates
Ora passiamo all’altra prospettiva, a pieno regime. L’obiezione di Allen Holub è che le stime sono sempre imprecise, di solito in modo esorbitante, e che gli “story point” erano stati concepiti per offuscare la durata, in modo che i manager smettessero di esercitare pressioni sui tempi — eppure i team li riconvertono immediatamente in ore, ricreando proprio quei punti di disfunzione che gli “story point” erano stati inventati per prevenire. La scala di Fibonacci non vi salva se ognuno di voi conserva per sé una tabella di conversione da punti a ore.
L’affermazione più incisiva, improntata ai dati, proviene da Vasco Duarte: nei progetti reali, il semplice conteggio delle storie permette di fare previsioni con la stessa precisione della somma dei relativi story point. Se ciò vale anche per il vostro lavoro, i punti sono pura formalità: avete fatto dei calcoli per arrivare alla stessa risposta che il conteggio vi aveva già fornito. Misurate invece la produttività e il tempo di ciclo; una coda in crescita è un indicatore anticipatore che potete prevedere, mentre la velocità è un indicatore ritardato.
E poi la mossa più incisiva dell’intero dibattito. Ron Jeffries, a cui viene comunemente attribuito il merito di aver inventato gli story point, ha fatto marcia indietro nel 2019: «Potrei aver inventato gli story point, e se così fosse, ora me ne rammarico.» Il suo problema riguarda specificatamente il loro utilizzo per prevedere quando il lavoro sarà completato e per confrontare i team. La sua alternativa non è «smettere di pianificare», bensì suddividere le storie in parti così piccole da richiedere un unico test di accettazione, idealmente di durata inferiore a un giorno ciascuna, in modo che non rimanga praticamente nulla da stimare.
In quali casi potremmo cambiare idea
Adotteremmo l’approccio #NoEstimates per un team il cui lavoro è già suddiviso in parti piccole e uniformi. Quando ogni story richiede all’incirca un giorno, il conteggio delle story e la somma dei punti, e la riunione di stima rappresenta un onere superfluo che si può eliminare — McConnell lo ammette apertamente, indicando il lavoro a ciclo rapido, in cui la missione consiste semplicemente nel «fare la prossima cosa più utile», come un contesto in cui le stime apportano ben poco.
Al contrario, abbasseremmo la guardia nei confronti dei punti nel caso opposto: un’organizzazione in cui le stime non si trasformano mai realmente in impegni e nessuno mette a confronto i team. In tal caso, il pericolo segnalato dal fronte contrario alle stime non sussiste, e i punti costituiscono semplicemente un innocuo spunto di conversazione. Il problema è che questo tipo di organizzazione è raro. L’uso strumentale è la norma, ed è per questo che il nostro verdetto va in questa direzione.
L’aspetto pratico
- Considerate il planning poker come uno strumento per individuare i disaccordi, non come uno strumento di previsione. Un 2 e un 13 assegnati alla stessa storia costituiscono il segnale: significa che il team non ha una visione condivisa del lavoro. Discutete finché il divario non si riduce; il risultato è il consenso raggiunto, non il numero finale.
- Si effettui la previsione sulla base della produttività e del tempo di ciclo, non sulla somma dei punti. Velocity costituisce un dato di riferimento per la pianificazione del team, ma non rappresenta mai una promessa verso l’esterno.
- Come afferma Cohn, occorre distinguere la stima dall’impegno. Una stima è un’ipotesi; nel momento in cui diventa una promessa, qualcuno ne ha modificato il significato senza avvisare il team.
- Se decide di utilizzare i punti, li mantenga relativi. Nel momento stesso in cui li associa alle ore, si ritrova a stimare la durata in modo velato — con tutta la pressione derivante dalle stime in ore, a cui si aggiunge un ulteriore livello di offuscamento.
- È meglio suddividere la storia piuttosto che definirne le dimensioni. Jeffries ha ragione quando afferma che gran parte del valore su cui verte il dibattito svanisce quando le storie sono talmente piccole che la stima assume un’importanza marginale.
Il numero non ha alcun valore; ciò che conta è la conversazione che lo ha generato. Quella singola frase risolve gran parte della discussione — e garantisce che una sessione di planning poker sia realmente utile, senza fingere di poter prevedere il futuro.
Domande frequenti
Dovremmo utilizzare gli story point o il metodo #NoEstimates?
Utilizzate qualsiasi metodo che favorisca il dialogo sulla stima e smettete di considerare il numero come una previsione. Gli story point sono utili per individuare eventuali divergenze: un ampio divario su una determinata storia indica che il team non ha una visione condivisa della stessa. #NoEstimates è la scelta giusta quando le vostre storie sono già suddivise in parti piccole e uniformi, poiché in tal caso il loro conteggio funge sia da previsione che da somma dei punti. In ogni caso, prevedete la consegna in base alla produttività e separate la stima dall’impegno.
L’inventore degli “story point” li ha davvero rinnegati?
Ron Jeffries, a cui viene comunemente attribuito il merito di aver coniato il concetto di “story point”, ha scritto nel 2019: «Potrei aver inventato gli story point e, se così fosse, ora me ne rammarico». La sua obiezione riguarda l’utilizzo di tali punti per prevedere le date di completamento e per confrontare o valutare i team. L’alternativa da lui raccomandata non è «nessuna pianificazione», bensì suddividere le storie in parti sufficientemente piccole da richiedere un unico test di accettazione.
Come si fa a pianificare il rilascio di una versione senza stimare ogni singola story?
Misurate il throughput — ovvero il numero di storie che il team porta effettivamente a termine ogni settimana — e proiettate il backlog residuo in base a tale ritmo. Vasco Duarte ha riscontrato che il conteggio delle storie consente di fare previsioni con la stessa precisione della somma dei punti storia; pertanto, una volta che le storie sono state suddivise in parti di dimensioni simili, i punti aggiungono ben poco rispetto a quanto già fornito dal conteggio.
Letture correlate
- Cosa sono gli story point? — cosa misurano e cosa non misurano.
- Story point contro ore — perché la conversione da story point a ore rappresenta il punto di scontro su cui entrambe le fazioni stanno in realtà discutendo.
- La velocità è un parametro utile? — l’altra faccia della medaglia: cosa accade quando la previsione diventa un obiettivo.
- Teatro Agile: la modalità di fallimento della performance — la stima come rituale da “cargo cult” e come distinguere una stima reale dalla messinscena.
- Planning Poker gratuito — uno strumento di dialogo, non uno strumento di previsione.