Cosa sono gli story point? Una stima dello sforzo, non del tempo

Gli story point misurano lo sforzo relativo di un’attività (la sua entità, complessità e incertezza sintetizzate in un unico numero), non le ore necessarie per portarla a termine. Si valuta la dimensione di un elemento del backlog confrontandolo con una storia di riferimento che il team ha già completato («questo è circa il doppio di quello»), anziché cercare di indovinare una durata. È proprio questo cambiamento a consentire alla stima di reggere il confronto con la realtà.

Perché misurare lo sforzo e non il tempo

Un team che effettua stime in ore, in realtà, formula due stime distinte: quella a cui crede l’ingegnere senior e quella che l’ingegnere junior mette per iscritto dopo aver arrotondato per apparire responsabile. Le persone non sono affidabili quando si tratta di rispondere alla domanda «quanto tempo ci vorrà?», ma sono sorprendentemente brave a valutare se «questo è più grande di ciò che abbiamo completato nello sprint precedente». Gli story point si basano proprio su quest’ultimo aspetto.

Il dimensionamento relativo consente al team di concordare che un elemento sia più grande di un altro senza che nessuno si impegni a fornire un numero di ore, il che consente di aggirare il bias di ancoraggio e quello di anzianità che le stime in ore comportano. Il numero che ne risulta non rappresenta una durata, bensì una posizione su una scala condivisa.

Valutare l’entità del lavoro in termini di impegno anziché di ore consente di aggirare tre problemi che affliggono le stime basate sulle ore:

• Una stima non costituisce un impegno. Le ore inducono le parti interessate a considerare le “8 ore” come una promessa; i punti fanno sì che la stima rimanga una previsione.
• Lo stesso compito richiede tempi diversi a persone diverse. Un punto riflette il lavoro, non la persona.
• La durata non tiene conto del rischio. Un’attività breve ma incerta può essere più rischiosa di una lunga e ben definita; pertanto, i punti tengono conto di tale incertezza.

Come funziona la stima dei story point

La maggior parte dei team esprime il proprio voto su una scala di tipo Fibonacci, 1, 2, 3, 5, 8, 13, nel corso di un round di planning poker. I divari si ampliano di proposito: più il lavoro è ampio, meno si sa realmente, quindi la scala smette di fingere che si possa distinguere un 9 da un 10. Sommando i punti che un team totalizza alla fine di ogni sprint si ottiene la velocità, ovvero l’unico risultato che i punti di previsione sono effettivamente destinati a produrre.

Se un elemento risulta più grande di circa un 13, ciò significa solitamente che la scala Le sta indicando di suddividerlo in parti che il team possa comprendere e portare a termine nell’arco di un singolo sprint.

Per una prima valutazione più rapida e approssimativa, alcuni team classificano l’intero backlog in base alle taglie delle magliette e convertono in punti solo il lavoro a breve termine una volta che questo è stato perfezionato.

In una sessione di Planning Poker, tutti rivelano la propria carta contemporaneamente, in modo che nessuno si lasci influenzare dalla voce più forte o da quella di chi ricopre una posizione di maggiore autorità. Laddove le stime più alte e quelle più basse divergono, le due persone interessate spiegano il proprio ragionamento; tale conversazione, che porta alla luce i presupposti e le complessità nascoste dietro al numero, ha solitamente un valore maggiore del numero stesso. La guida completa al planning poker illustra le meccaniche di gioco.

La causa principale di insuccesso è rappresentata dal team che inizia a riconvertire i punti in ore. Nel momento in cui tale tabella di conversione viene pubblicata sul wiki, ogni discussione relativa alle stime si riduce a una discussione sulla durata e la nozione di sforzo relativo viene meno.

Quale opera dovrebbe indicare?

In ogni riunione di perfezionamento emergono due domande: questo lavoro dà diritto a dei punti? E, in caso affermativo, quanti? La scala serve proprio a rispondere alla domanda “quanti”. Per quanto riguarda la domanda “se ne dà diritto”, esiste una regola empirica: assegnare punti a tutto ciò che il team consegna nell’ambito del lavoro che si è impegnato a svolgere, in modo che l’indicatore di velocità rifletta effettivamente dove viene impiegata la capacità.

Errori

Un bug con una causa nota e una soluzione chiara costituisce una story. Presenta criteri di accettazione (“il modulo non accetta più quantità negative”), un ambito definito e dimensioni ragionevoli; pertanto, lo si voti come qualsiasi altra story. Il lavoro sui bug e quello sulle funzionalità competono per la stessa capacità, e la velocità dovrebbe riflettere tale situazione.

L’eccezione è rappresentata dal bug la cui natura è «non sappiamo ancora cosa ci sia lì dentro»: indagare sul danneggiamento dei dati, capire perché il p99 sia raddoppiato, i clienti continuano a segnalarlo e non riusciamo a riprodurlo. La correzione non è quantificabile poiché la causa è sconosciuta; pertanto, una votazione in story point misura semplicemente ciò che il team spera di scoprire. Inserite tali attività in un percorso di indagine a tempo determinato: dedicate un giorno o due alla ricerca, quindi tornate con una vera e propria story relativa a ciò che avete scoperto.

Test e controllo qualità

Gli story point definiscono l’entità del lavoro da svolgere tra il momento in cui «la story entra nello sprint» e quello in cui «la story è pronta per la consegna», il che include qualsiasi attività di controllo qualità che il team svolga come parte del processo di completamento: test automatizzati, verifiche manuali, controlli di accessibilità, revisione della sicurezza. La story non è considerata completata al momento del merge del pull request; lo è solo quando soddisfa la definizione di completamento.

I team che concentrano il lavoro esclusivamente sullo sviluppo e aggiungono separatamente il controllo qualità finiscono per assumersi impegni eccessivi in ogni sprint, poiché il controllo qualità rappresenta il collo di bottiglia che nessuno ha quantificato. Se un team di controllo qualità separato si occupa dei test, la story comporta comunque i costi dal lato degli sviluppatori legati alla collaborazione con esso: preparazione della build, stesura del piano di test, risposta alle domande. Quella parte non è gratuita, quindi rimane inclusa nella stima.

Perché raramente è auspicabile un articolo incentrato su un unico argomento

I punteggi sono relativi, pertanto un 1 ha senso solo se confrontato con un 2, un 3 o un 8. Quando una squadra registra una serie ininterrotta di risultati da 1 punto, tale gradazione viene meno: ogni risultato di modesta entità è un 1, ogni risultato più consistente è un 2 o un 3, e la scala si riduce a un semplice lancio di moneta.

La soluzione non consiste nel vietare i valori pari a “1” (questa è la versione distorta della regola). Consiste piuttosto nel chiedersi perché gran parte del lavoro si concentri nella parte inferiore della scala. Di solito la storia di riferimento si è spostata: il team è diventato più veloce e l’originario “1” è ora più piccolo di qualsiasi cosa venga rilasciata, quindi occorre scegliere un riferimento più recente che il team ricordi e ridefinire il punto di riferimento. A volte il team sta scomponendo eccessivamente durante l’affinamento, estraendo ogni criterio di accettazione come se fosse una storia a sé stante: «aggiornare il testo del pulsante» non è una storia, ma un criterio di accettazione relativo a una storia più ampia. E talvolta il lavoro è effettivamente di entità ridotta (un intervento di manutenzione trimestrale, una modifica al testo che richiede la revisione legale, una regolazione della configurazione che interessa l’ambiente di produzione); in tal caso, i punti svolgono la loro funzione e non c’è nulla da correggere.

L’indicatore da tenere d’occhio non è «mai un 1». È il fatto che i 1 costituiscano la maggior parte del backlog. Uno o due per sprint vanno bene. Se una storia su due riceve un 1, significa che è da troppo tempo che non viene sollevata la questione della calibrazione.

I punti storia e la retrospettiva

La stima è uno degli aspetti più ricorrenti che un team esamina durante la propria retrospettiva di sprint. Quando gli elementi vengono sistematicamente sottostimati o sovrastimati, quando la velocità subisce oscillazioni significative o quando il lavoro “completato” continua a essere riaperto, la retrospettiva rappresenta l’occasione in cui il team ricalibra la propria percezione condivisa delle dimensioni e affina il modo in cui suddivide il lavoro. L’accuratezza delle stime migliora grazie a questo ciclo di feedback, non cercando di impegnarsi maggiormente in fase iniziale.

Domande frequenti

Cosa sono gli story point nell’agile?

Gli story point sono un’unità di stima relativa: un numero che indica l’entità di un’attività (in termini di impegno, complessità e incertezza considerati nel loro insieme) rispetto a una storia di riferimento che il team ha già realizzato. Non sono, di proposito, una misura del tempo. Il team valuta la dimensione di ciascuna attività rispetto alle altre, piuttosto che in termini di tempo.

Perché utilizzare gli story point anziché le ore?

Le persone hanno difficoltà a stimare il tempo in termini assoluti, ma sono brave a valutare se una cosa sia più grande di un’altra, e gli story point fanno leva su questa capacità. Inoltre, evitano la trappola di considerare una stima come un impegno, tengono conto del fatto che lo stesso compito richieda tempi diversi a persone diverse e integrano la complessità e il rischio, non solo la durata. Nel corso di alcuni sprint, la velocità di un team espressa in punti diventa una previsione più affidabile rispetto alla somma delle stime in ore.

Come si stimano gli story point?

La maggior parte dei team utilizza il “planning poker”. Qualcuno illustra un elemento del backlog, il team ne discute e ciascuno sceglie in privato un valore da una scala condivisa, solitamente una sequenza di tipo Fibonacci (1, 2, 3, 5, 8, 13). Tutti rivelano contemporaneamente le proprie scelte; laddove le stime differiscono notevolmente, chi ha espresso il valore più alto e chi quello più basso spiegano il proprio ragionamento e il team procede a una nuova votazione fino a raggiungere un consenso. La discussione che porta alla luce le complessità nascoste è spesso più preziosa del numero in sé.

I bug dovrebbero avere dei punti storia?

Sì, quando il bug ha una causa nota e una soluzione chiara: si tratta di una story come qualsiasi altra, e segnalarlo garantisce che la velocità rifletta fedelmente la destinazione della capacità. L’eccezione è rappresentata dal bug esplorativo di cui non è ancora possibile definire l’ambito; inseritelo in un percorso di indagine a durata prestabilita e valutate l’entità della soluzione effettiva una volta individuata la causa.

I punti storia includono i test?

Sì. I punti quantificano tutte le fasi che intercorrono tra l’inserimento di una funzionalità nello sprint e il momento in cui questa è pronta per la consegna, compresi i test e il controllo qualità che il team effettua nell’ambito della propria definizione di “completato”. Se si assegnano punti solo al lavoro di sviluppo, lo sprint va ogni volta oltre i tempi previsti, poiché il controllo qualità rappresenta il collo di bottiglia di cui nessuno ha tenuto conto.

Perché è opportuno evitare le notizie che trattano un solo argomento?

Qualcuno va bene. Tuttavia, se la maggior parte degli incarichi arretrati è classificata come “1”, la storia di riferimento del team si è spostata e la scala è crollata, per cui tutto viene percepito come “minuscolo” o “più grande”. È opportuno ricalibrare la scala in base a una storia di riferimento recente, anziché ridurne l’entità.

È possibile confrontare gli story point tra i vari team?

No. Uno story point è calibrato in base alla percezione della dimensione relativa propria di un singolo team, pertanto il valore 5 di un team non corrisponde al valore 5 di un altro team. Il confronto tra la velocità o i totali dei punti tra i vari team è privo di significato e, se utilizzato come obiettivo, risulta addirittura dannoso: spinge i team a gonfiare le stime. Gli story point sono uno strumento di pianificazione per le previsioni di un singolo team, non un indicatore di produttività da utilizzare a fini comparativi.

Approfondimenti

• Perché gli story point utilizzano la sequenza di Fibonacci: perché gli intervalli si allargano man mano che i numeri aumentano.
• Story point vs ore: la trappola della conversione e cosa fare quando qualcuno ha bisogno di una data.
• Velocity: trasformare i punti di svolta in una previsione senza alterarli.
• Tecniche di stima agile: quale metodo utilizzare in quali circostanze e in che modo ciascuno di essi può fallire.
• Retrospettiva di sprint: l’occasione in cui i team ricalibrano le stime che continuano a rivelarsi errate.
• Guida alla stima agile: il quadro completo, dal planning poker alla suddivisione delle storie.
• Planning Poker gratuito per team agili: valutate insieme il vostro backlog in tempo reale.