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

Gli story point misurano lo sforzo relativo, la complessità e l’incertezza del lavoro — non le ore. Come valutare l’entità di un lavoro rispetto a una storia di riferimento e le domande che mettono in difficoltà i team.

Gli story point misurano lo sforzo relativo di un’attività — ovvero la sua entità, complessità e incertezza sintetizzate in un unico numero — e 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 semplice cambiamento che consente 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à, sta in realtà formulando due stime: 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 nell’ultimo sprint». Gli story point si basano su quest’ultimo aspetto.

Il dimensionamento relativo consente al team di concordare che un elemento sia più grande di un altro senza che nessuno debba impegnarsi a fornire un numero di ore — il che consente di evitare i pregiudizi legati all’ancoraggio e all’anzianità che le stime in ore comportano. Il numero che ne risulta non rappresenta una durata, bensì una posizione su una scala condivisa.

La scala e la funzione dei punti

La maggior parte dei team vota 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à — l’unico dato che i punti di previsione sono effettivamente destinati a produrre.

La principale causa di insuccesso è rappresentata dal team che inizia a riconvertire i punti in ore. Nel momento in cui quella 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 dovreste 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, votatela 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é p99 è 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 durata prestabilita: dedicate un giorno o due alla ricerca, poi 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 PR, ma solo quando soddisfa la definizione di completamento.

I team che concentrano il lavoro esclusivamente sullo sviluppo e aggiungono il controllo qualità (QA) separatamente finiscono per assumersi impegni eccessivi in ogni sprint, poiché il QA rappresenta il collo di bottiglia che nessuno ha tenuto in considerazione. 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 punto

I punteggi sono relativi, quindi 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 modesto è 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: quella è la versione “cargo-cult” 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’originale “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 il perfezionamento, 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 correttamente la loro funzione e non vi è 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.

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à — considerando insieme lo sforzo richiesto, la complessità e l’incertezza — rispetto a una storia di riferimento che il team ha già completato. Non rappresentano, di proposito, una misura del tempo. Il team valuta ogni elemento in relazione agli altri, piuttosto che in base al tempo.

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 permette di mantenere la “velocity” allineata alla reale disponibilità di risorse. L’eccezione è rappresentata dal bug esplorativo di cui non è ancora possibile definire l’ambito; inseritelo in un percorso di indagine con un limite di tempo prestabilito 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 gli articoli che trattano un solo argomento?

Qualcuno va bene. Ma se la maggior parte delle attività arretrate è classificata come “1”, la storia di riferimento del team si è spostata e la scala è crollata: tutto viene percepito come “piccolo” o “più grande”. È opportuno ricalibrare la scala in base a una storia di riferimento recente, anziché ridurne l’ampiezza.

Letture correlate