Story point contro #NoEstimates: il nostro verdetto

Nessuna delle due posizioni prevale in modo assoluto. Si effettui una stima per costruire una comprensione condivisa e individuare eventuali disaccordi; non si effettui una stima per prevedere una data, ma si ricorra piuttosto a una previsione basata sulla produttività. Si analizzino in modo critico gli story point, il movimento #NoEstimates e l’ideatore che ha rinnegato i punti, per poi giungere a una conclusione.

Nessuna delle due parti prevale in modo definitivo. Si effettui una stima per raggiungere una comprensione condivisa e individuare eventuali disaccordi; non si effettui una stima per prevedere una data, ma si ricorra piuttosto 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 punti — ma in realtà non lo è. Entrambe le parti hanno ragione su alcuni aspetti 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 gli elementi che reggono alla prova di uno sprint reale.

I motivi a favore degli story point

L’argomentazione di Mike Cohn, che rappresenta la posizione definitiva a favore dei punti, non ha mai riguardato realmente il numero in sé. Il punto è che l’atto stesso di formulare stime relative 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 appaia inefficace. Se invece le si mantiene distinte, essa svolge un ruolo concreto.

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 i “story point” erano stati concepiti per nascondere la durata, in modo che i manager smettessero di esercitare pressioni sui tempi; tuttavia, i team li riconvertono immediatamente in ore, ricreando proprio quei punti di disfunzione che i “story point” erano stati inventati per prevenire. La scala di Fibonacci non vi salva se ognuno, per conto proprio, dispone di una tabella di conversione da punti a ore.

L’affermazione più incisiva in materia di 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 aritmetici 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 generalmente 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 specificamente l’uso di tali punti per prevedere quando il lavoro sarà completato e per confrontare i team. La sua alternativa non è «smettere di pianificare». Consiste nel 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 circostanze cambieremmo idea

Adotteremmo l’approccio #NoEstimates al 100% 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 funge da previsione e sommando i punti, la riunione di stima diventa un onere che è possibile eliminare. Lo stesso McConnell lo ammette, indicando il lavoro a ciclo rapido — in cui la missione è semplicemente «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 dagli oppositori delle stime non sussiste, e i punti costituiscono semplicemente un innocuo spunto di conversazione. Il problema è che questo tipo di organizzazione è raro. L’uso strumentale delle stime è la norma, ed è per questo che il nostro verdetto va in questa direzione.

L’aspetto pratico

one story 3 13 one dev another dev the gap is the point talk it out — don’t average A 3 beside a 13 means you’re picturing different work.
Il risultato del Planning Poker non è il numero, bensì il divario. Un 3 accanto a un 13 indica che due persone hanno una visione diversa del lavoro; pertanto, colmate tale divario attraverso il dialogo, non limitatevi a trovare un compromesso.
  • 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. Ciò 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 una 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 in alcun caso una promessa verso l’esterno.
  • Come afferma Cohn, occorre distinguere tra stima e impegno. Una stima è una previsione; nel momento in cui diventa una promessa, qualcuno ne ha modificato il significato senza comunicarlo al 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 confusione.
  • È meglio suddividere la storia piuttosto che dimensionarla. 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 discussione che ha portato a stabilirlo. Quella singola frase risolve gran parte del dibattito e garantisce che una sessione di planning poker sia realmente utile, senza pretendere 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 come indicatori di disaccordo: un’ampia dispersione dei valori relativi a una storia significa 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 è possibile pianificare un rilascio senza stimare ogni singola story?

Misuri il throughput, ovvero il numero di story che il team porta effettivamente a termine ogni settimana, e proietti il backlog residuo in base a tale ritmo. Vasco Duarte ha riscontrato che il conteggio delle story consente di effettuare previsioni con un’accuratezza paragonabile a quella ottenuta sommando gli story point; pertanto, una volta che le story sono state suddivise in parti di dimensioni simili, i punti aggiungono ben poco rispetto a quanto già fornito dal conteggio.

Approfondimenti