Velocity, come misurare i progressi del team
Autore: Franco Godone Professional Scrum Trainer e ICF Associate Certified Coach Pubblicato il 18 dicembre 2015 alle ore 22:25 Aggiornato il 26 agosto 2026 alle ore 15:07
In sintesi
Nelle metodologie agili, la velocity descrive il lavoro completato da un team in un'iterazione e può aiutare a pianificare gli Sprint futuri. Si calcola sommando gli story point delle user story completate. È specifica per ogni team e non deve essere confrontata tra gruppi diversi né usata come obiettivo da aumentare. Non misura valore, outcome o progressi verso gli obiettivi.
Argomenti
Nelle metodologie agili, la velocity è l'unità di misura che consente di tenere traccia di quanto lavoro può svolgere il team durante un'iterazione. È uno strumento molto 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.
Il concetto di velocity
Nell'articolo precedente abbiamo visto come eseguire le stime in un team agile e come ogni membro del team assegni a ciascuna attività un punteggio relativo, chiamato story point.
La somma degli story point "completati" determina la velocity di ciascuno Sprint, e la media aritmetica del punteggio di ciascuno Sprint determina quanto un team è mediamente in grado di realizzare in un'iterazione.
Come si calcola la velocity
Per il calcolo della velocity si prendono dunque in considerazione soltanto le user story che sono state completate e validate al termine di ciascuno Sprint in base alla Definition of Done.
Se per esempio in uno Sprint ci sono n user story e la somma degli story point di tutto ciò che è stato completato è uguale a 25, la nostra velocity per quella determinata iterazione è 25. Se nello Sprint successivo si hanno n user story completate per un totale di 19 story point, la nostra velocity per quello Sprint è 19.
I due numeri di per sé non ci dicono molto e non sono particolarmente utili al fine di prevedere quanto lavoro siamo in grado di completare in un'ottica più di lungo termine. Per capire quanti story point saranno verosimilmente completati negli Sprint successivi, dobbiamo fare una media aritmetica del punteggio totale di ciascuna iterazione.
Nel nostro caso:
velocity media = (25 SP + 19 SP) / 2 = 22 SP
La nostra velocity media, in relazione ai due Sprint, è 22 SP. Se il terzo Sprint avrà un totale di 10 SP, la media dei tre Sprint sarà 18 SP. E così via. Per avere una stima attendibile della capacità di un team, e fare previsioni sui rilasci in maniera più efficace, conviene prendere in considerazione almeno 4 o 5 Sprint.
Di solito, quando si parla genericamente di velocity, si fa riferimento alla velocity media e mai alla velocity di una singola iterazione, che come abbiamo visto non è molto indicativa.
La velocity serve come dato storico per pianificare, non come obiettivo da aumentare. Cercare di migliorare il punteggio a ogni iterazione porta facilmente a modificare le stime senza aumentare il valore prodotto.
Velocity in un team appena formato
Se sei alla prima iterazione con un team con cui non hai mai lavorato e hai bisogno di avere un'indicazione empirica della velocity perché devi produrre un piano di rilascio, ti consiglio di identificare una baseline stimando insieme al team di sviluppo una delle user story del tuo Product Backlog. Magari una abbastanza complessa e articolata.
Una volta identificato l'effort della baseline, prendi in esame un sottoinsieme di user story che vuoi includere nella stima e verificane la dimensione relativamente alla baseline. Esempio: se la tua baseline è il "menu principale" della tua applicazione, e il punteggio è di 8 SP, puoi verificare se lo "splash screen" è pari al doppio, alla metà, a un terzo, e così via.
Una volta identificato l'effort per ciascuna user story, puoi individuarne i singoli task e preparare il piano di lavoro senza convertire gli story point in ore. Story point e ore esprimono misure diverse.
Tuttavia, molti team trovano utile stimare i singoli task, ovvero ciascuna sotto-attività necessaria al completamento di una user story, in ore. Fai riferimento all'articolo sullo Sprint backlog in Scrum per avere uno spunto su come procedere.
Quando hai processato, insieme al tuo team, abbastanza user story, puoi formulare previsioni usando i dati storici e rendendo esplicita l'incertezza.
Ti consiglio di utilizzare questa tecnica della baseline insieme ai dati osservati dal team quando vuoi formulare previsioni sui rilasci, invece di fidarti esclusivamente del dato della velocity.
Velocity diversa in team diversi
Bene, adesso che abbiamo la velocity del nostro team possiamo finalmente dimostrare al mondo quanto siamo bravi! Beh no, non funziona proprio così. Come hai già capito gli story point sono una misura relativa, e così è la velocity.
Il fatto che il Team 1 abbia una velocity di 50 SP non significa necessariamente che produca più "valore" del Team 2 che ha una media di 25 SP. La velocity è una misura propria di ciascun team e non ha alcun senso compararla con altri gruppi di lavoro.
Per concludere, un errore da evitare è la misurazione della velocity di ciascun membro del team con il fine di rilevarne le performance. La velocity ha senso soltanto come misura di gruppo e non individuale. Descrive un output stimato; i progressi verso Sprint Goal e Product Goal, il valore e gli outcome richiedono osservazioni distinte.