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 non deve comunque limitare le ambizioni di un team. Se la media è di 15 SP, non vuol dire che dobbiamo giocare al ribasso e pianificare soltanto per quella quantità di story point, anzi può essere stimolante provare a migliorare il proprio punteggio ad ogni iterazione.
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 identificarne i singoli task e procedere con la stima in ore di ciascuna sotto-attività necessaria al completamento della feature. 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 da coprire una settimana di lavoro, puoi proiettare le tue stime su periodi di tempo più estesi e cercare di avere una corrispondenza empirica tra story point e ore di lavoro. Ricordati sempre di lasciare un po’ di buffer, non meno del 20%.
Ti consiglio di utilizzare questa tecnica della baseline anche nel caso in cui volessi previsioni più accurate sui rilasci, invece di fidarti esclusivamente sul 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.
È FINALMENTE DISPONIBILE IL VIDEOCORSO DI AGILE WAY!
CORSO APPROFONDITO SU SCRUM E SULLE METODOLOGIE AGILI
Aggiornato all’ultima versione della guida ufficiale di Scrum!
Più di 3,5 ore di video lezioni su Scrum, ideale per prepararsi a un esame di certificazione PSM I e per comprendere i valori, i principi e le pratiche dei metodi Agili. In questo corso imparerai:
- Origine, nascita e significato delle metodologie Agili
- Differenze tra Scrum e i modelli tradizionali
- Tutte le componenti del framework Scrum, i valori, le pratiche e le metriche
- Come gestire al meglio un progetto e un prodotto con Scrum
- Come mantenere un’attenzione continua al valore generato e al cliente
- Simulatore di esame di certificazione (80 domande)
- Tanto altro…
* Offerta limitata nel tempo
[…] informazioni sull’addon sono reperibili qui. Si consiglia la lettura dell’articolo seguente, dove sono spiegati, in maniera molto semplice e chiara alcuni concetti di […]
[…] ragione, ma qui la delivery serve subito.”La fretta è ben diversa dall’efficienza e dalla velocity. La fretta è l’alibi di chi non ha saputo gestire bene il progetto prima, o la conseguenza di […]