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 che richiederà. 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é ipotizzarne la durata. È proprio questo cambiamento di approccio 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à, 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 del lavoro che abbiamo completato nell’ultimo sprint». Gli story point si basano proprio su questo secondo aspetto.

Il metodo di valutazione relativa 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.

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. L’indicazione delle ore induce le parti interessate a considerare le “8 ore” come una promessa; l’uso dei punti fa sì che la stima rimanga una previsione.
• Lo stesso compito richiede tempi diversi a persone diverse. Un punteggio riflette il lavoro svolto, 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.

La scala e la funzione dei punti

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 ottenuti da un team al termine di ogni sprint si ottiene la velocità, ovvero il 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 vi 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 un giro 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 gerarchica più elevata. 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, è solitamente più preziosa del numero stesso. La guida completa al planning poker illustra le meccaniche di gioco.

La principale causa 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 il concetto 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, 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é 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 uno o due giorni all’analisi, quindi tornate con una vera e propria story relativa a ciò che avete individuato.

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 tutte le attività di controllo qualità che il team svolge come parte del processo di completamento: test automatizzati, verifica manuale, controlli di accessibilità e 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 dello sviluppo 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 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’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 raffinamento, 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 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” viene continuamente 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 esprime 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à completato. Non rappresentano, 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 non sono in grado di stimare con precisione il tempo assoluto, ma sono brave a valutare se una cosa è più grande di un’altra, e gli story point si basano proprio su questa capacità. Inoltre, evitano la trappola di considerare una stima come un impegno, tengono conto del fatto che lo stesso compito richiede 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 calcolano gli story point?

La maggior parte dei team utilizza il “planning poker”. Qualcuno illustra un elemento del backlog, il team ne discute e ciascuno assegna in privato un valore tratto da una scala condivisa, solitamente una sequenza simile a quella di Fibonacci (1, 2, 3, 5, 8, 13). Tutti rivelano contemporaneamente il proprio voto; laddove le stime differiscono notevolmente, chi ha espresso il voto 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 segnalarla garantisce che la velocità rifletta fedelmente l’impiego 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 gli articoli che trattano un solo argomento?

Qualcuno va bene. Tuttavia, se la maggior parte delle attività arretrate è 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 il tutto in base a una storia di riferimento recente, anziché ridurre la scala.

È possibile confrontare gli story point tra i vari team?

No. Uno story point è calibrato in base alla percezione della dimensione relativa propria di un determinato team, pertanto il valore 5 di un team non corrisponde al valore 5 di un altro team. Il confronto tra la velocità o il totale 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 finalizzato alle previsioni di un singolo team, non un indicatore di produttività da utilizzare a fini comparativi.

Letture correlate

• Perché i punti storia utilizzano la sequenza di Fibonacci: perché gli intervalli si allargano man mano che i numeri aumentano.
• Story point contro 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: in cui i team ricalibrano le stime che continuano a rivelarsi errate.
• Guida alla stima agile: il percorso completo, dal planning poker alla suddivisione delle storie.
• Planning Poker gratuito per team agili: valutate insieme le dimensioni del vostro backlog in tempo reale.