trianglee

Insights Sul rilascio di prodotto e la cinematica degli story Points

Linkedin Twitter
Scroll
28/10/2020

Articoli

di Stefano Muro

 

Le domande che tutti i product manager si fanno sono più o meno sempre quelle:

Quando riusciremo a rilasciare? Quanto ci verrà a costare?

 

L’illusione della risposta nell’approccio tradizionale al prodotto sta in quelle tre variabili magiche che sono: quanto abbiamo speso fino ad ora, quanto ci rimane da fare e quanto tempo abbiamo ancora.

 

Nel momento in cui si trovano a interagire con un team agile che applica  scrum, i nostri product manager si trovano un po’ in difficoltà perché, mentre per quanto riguarda lo speso e il tempo a disposizione, non molto è cambiato, rispondere a quanta roba c’è ancora da fare è un pochino più difficile: non si trovano infatti difronte a una tranquillizzante percentuale di avanzamento o meglio ancora difronte ad un numero di ore ancora da spendere, ma difronte a questo oggetti misteriosi che si chiamano story points.

 

Incomincia quindi l’ossessione di capire quanti story “valgono” tutte le cose rimanenti da fare, numero che finisce per salire continuamente nel tempo (ma non era meglio fare una bella analisi upfront di tutto quello che c’è da fare invece di stimare continuamente un pezzo per volta? Si chiedono), e l’ansia di capire se la “velocity” (il numero di story points implementati per iterazione) aumenta o diminuisce, come le azioni in borsa: qualcosa completamente al di fuori del loro controllo.

 

Di recente mi è capitato di leggere questo articolo di .. e, sebbene non l’abbia apprezzato sul momento, mi ha portato a fare una riflessione: l’errore principale che si fa nell’utilizzare gli story point è considerarli una stima della distanza verso un obiettivo (quanta roba c’è da fare) mentre invece è una stima del tempo (dell’effort che ci vuole ad arrivarci). Questa differenza è determinante.

 

Supponiamo che la realizzazione di una certa funzionalità sia come andare da Roma a Pisa e che sia fissata come unità di confronto a 3 Story points di effort.

Se dovessimo stimare una nuova funzionalità, che è andare da Roma a Milano, quanti story points mi costa? Istintivamente viene da dire 5 story points perché assimiliamo il tempo che ci vuole con la distanza: in realtà dipende da molte altre cose.

Prima di tutto il tempo che ci metto per andare a Milano, rispetto a quello che ci ho messo per andare a Pisa dipende dalla strada che utilizzo (che possiamo assimilare alla soluzione) e al mezzo che ho a disposizione (competenze tecniche e di dominio del mio team). Inutile dire che poter utilizzare mezzi diversi apre alla possibilità di percorrere strade diverse: se le mie competenze sono pari ad una auto non posso percorrere le rotaie dell’alta velocità, cosa che invece posso fare se le mie competenze sono pari ad un frecciarossa.

La stima del tempo dipende inoltre da rischi quale il traffico (utilizzo di risorse condivise), condizioni della strada/lavori in corso (debito tecnico) e possibili incidenti. Questi rischi possono essere gestiti proattivamente, cercando una strada (soluzione) o un mezzo (skill) che li mitighi, o reattivamente, cambiando strada/mezzo in corsa quando ci si accorge che i tempi per arrivare a destinazione si stanno allungando.

 

Questo è proprio il bello dell’approccio agile, andare per tappe e ad ogni tappa rivalutare la strada da percorrere o i mezzi da utilizzare per arrivare a destinazione il prima possibile.

 

Tornando ai nostri Story Points, per riuscire ad arrivare in tempo alla delivery il problema non è (solo) aumentare il numero di story point che si implementano in una iterazione (si potrebbe dire il tempo efficace che dedichi alla realizzazione del prodotto all’interno di una iterazione) quanto piuttosto:

 

  • determinare la soluzione che ci porta a destinazione il più velocemente possibile e
  • dare al team il tempo di acquisire nuovi mezzi per poter trovare soluzioni più veloci.

 

In pratica: aumentare il numero di cose fatte che ci avvicinano alla delivery mantenendo gli Story Points costanti.

 

Il consiglio che quindi mi sento di dare ai Product Manager è di essere più navigatori, valutando anche le opzioni di diversi mezzi di trasporto, e meno tachimetri (fermo restando che il navigatore deve tenere in conto anche la velocità).