Che cos’è e importanza della velocity in Agile

Introduzione alla velocity in Agile

Nelle metodologie agili e in particolare nel framework Scrum, la velocity (o velocità del team) è l’unità di misura che consente di tenere traccia di quanto lavoro può svolgere il team durante un’iterazione o uno sprint. Questo è uno strumento fondamentale ed utile per fare proiezioni su cosa può essere pianificato nello Sprint successivo. Spesso la velocity è utilizzata anche come indicazione di massima per capire cosa è possibile realizzare nel medio termine, e per impostare a grandi linee una roadmap. D’altra parte, usato male come indicatore di prestazioni per la gestione può essere totalmente controproducente.

Cos’è la velocity Agile?

Più in dettaglio, la velocità è un indicatore utilizzato su progetti gestiti usando un metodo agile, ad esempio come Scrum. La velocità agile consente di determinare lo sforzo che un team di sviluppo è in grado di fornire per svolgere le attività programmate in uno sprint ed è espressa in numero di punti.

Il proprietario del prodotto inserisce un certo numero di funzionalità da eseguire, o elementi generalmente formalizzati sotto forma di storie utente, nel backlog del prodotto. Il team di sviluppo assegna a ciascun articolo arretrato del prodotto (o PBI) un numero di punti. Questi punti rappresentano sia la complessità che la durata della realizzazione del PBI, stimate empiricamente. Questa non è una scala lineare e la sequenza di Fibonacci viene spesso utilizzata per una buona approssimazione.

Inoltre, i valori che possono essere assegnati sono:

• 1 per un’attività estremamente semplice, come ad esempio la correzione di un’etichetta;
• 2, 3, 5 per un’attività leggermente più complessa, come la creazione di un semplice modulo di iscrizione;
• 8, 13, 21, 34, 55, 89, 144 se non ci sono abbastanza informazioni per stimare l’attività in modo appropriato.

Inoltre, esistono diversi metodi di stima come il T-shirt Sizing (dimensionamento delle magliette), ad esempio, in cui vengono utilizzate le taglie delle magliette o il planning poker più noto per la pianificazione.

La velocità Agile del team di sviluppo viene dunque calcolata dopo uno sprint (il primo sprint). È sufficiente aggiungere i valori di tutti i PBI completati e consegnati durante lo sprint. Ad esempio, se alla fine dello sprint, il team ha raggiunto un PBI con 5 punti, tre PBI con 3 punti, due PBI con 1 punto e c’è ancora un PBI con 3 punti in corso, non ancora finito, la velocità Agile sarà 16 (l’ultimo PBI a 3 punti non viene preso in considerazione poiché non è ancora terminato).

Ma se la velocità Agile viene calcolata solo alla fine dello sprint, come può essere uno strumento di prevedibilità?

In effetti, ci vorranno tra tre e cinque sprint per stabilizzare la velocità del team di sviluppo. Lo sprint 1 è generalmente complesso. Si tratta di iniziare con un team i cui membri non si conoscono necessariamente né i processi. La velocità è raramente molto alta ma aumenterà gradualmente durante i primi tre o quattro sprint fino a quando non si stabilizza. La velocità agile è quindi ottimale ed è relativamente rappresentativa, anche se rimane una stima, dello sforzo che il team è in grado di produrre durante uno sprint.

Come si usa la velocity Agile?

Una volta stabilizzata la velocità Agile, è quindi possibile prevedere in modo abbastanza fedele il numero di punti di sforzo che il team potrebbe raggiungere e quindi ottimizzare la selezione di PBI da effettuare durante il prossimo sprint.

L’istituzione di un grafico di burndown evidenzierà la velocità accumulata durante i vari sprint e il numero di punti rimanenti nel backlog del prodotto (product backlog). Grazie a questo strumento, sarà possibile seguire graficamente l’avanzamento degli sviluppi e pianificare la progressione dei prossimi sprint in base alla velocità media del team di sviluppo.

Potrebbe anche essere interessante mantenere una riserva di punti che non è direttamente assegnata all’esecuzione di un compito specifico durante uno sprint. In effetti, il principio di un metodo agile è quello di essere in grado di adattarsi ai cambiamenti, ed è comune che un compito da svolgere venga identificato solo durante uno sprint, o che un cambiamento di priorità o un problema tecnico causino complicazioni. Questa riserva di punti consentirà di tenere conto di questi vari compiti oltre ad altri senza compromettere la consegna prevista al termine dello sprint.

Una volta stabilizzata la velocità Agile, è quindi possibile scegliere i diversi PBI che potrebbero essere affrontati nello sprint successivo in base ai punti assegnati in precedenza. La velocità nei seguenti sprint deve essere più o meno la stessa dello sprint corrente; sarà possibile pianificare in anticipo il contenuto di più consegne mantenendo la capacità di adattamento.

È molto importante che la velocità di un team sia stabile e per noi non cercare di aumentarla in modo permanente. La prevedibilità degli sprint è efficace solo se la velocità non cambia o cambia molto poco. L’aumento della velocità a tutti i costi, mentre stabilizzato, può solo avere un effetto negativo sulla realizzazione. Di solito sarà a scapito della qualità degli sviluppi e della soddisfazione del cliente.

Bisogna notare, inoltre, che la velocità è un indicatore specifico del team, quindi confrontarla con quella di un altro team non ha assolutamente senso. Il team con una velocità inferiore può avere l’impressione di dover provare se stesso o di aumentarlo artificialmente sopravvalutando, ad esempio, gli ordini iniziali. È quindi probabile che ci si trovi con velocità crescenti e una produttività reale che diminuisce.

Infine, come si può bene capire ed intuire, la velocità Agile è un indicatore alimentato dal team di sviluppo e destinato al team stesso. Usato bene, può migliorare la prevedibilità sui prossimi sprint. Invece, abusato, può essere la fonte di una maggiore pressione sul team e della sua demotivazione.