Guida Scrum | 34. Velocità nello Scrum – Velocità del Team di Sviluppo

La Velocità in Scrum ti aiuta a determinare il tasso con cui il Team Scrum completa i compiti. Possiamo definirla come il numero medio di Story Points completati in uno Sprint. La Velocità può anche stimare la durata di un progetto basata sul progresso del lavoro già completato. Tuttavia, questo ha senso solo per un team maturo che lavora a un ritmo uniforme e costante. Dai un’occhiata a cosa sia la Velocità e come farla funzionare al meglio per te!

Velocità in Scrum – indice dei contenuti:

1. Velocità in Scrum – Introduzione
2. Velocità attuale e pianificata
3. Difficoltà e rischi associati alla Velocità in Scrum
4. Riepilogo

Velocità in Scrum – Introduzione

La Velocità è un metodo opzionale ma popolare per misurare il ritmo di un Team Scrum. Questo perché una Velocità stimata con precisione consente di prevedere, in una certa misura, il tempo necessario per completare un progetto. Tuttavia, è una misura che può essere applicata solo a un determinato Team di Sviluppo, che eseguirà compiti che ha “valutato” autonomamente utilizzando un’unità familiare, come gli Story Points, ad esempio.

La Velocità del Team di Sviluppo è spesso presentata sotto forma di un Grafico della Velocità. Sull’asse X sono segnati gli Sprint consecutivi. Sull’asse Y, invece, troveremo il numero di Story Points o altre unità corrispondenti che sono stati completati in un dato Sprint. Con il Grafico della Velocità, il Team Scrum ottiene una chiara visione delle variazioni nel ritmo del proprio lavoro. Se la linea segnata sul grafico è in salita, significa che il Team sta ottimizzando la propria efficienza o riducendo il valore degli Story Points. Sia il Scrum Master che il Product Owner dovrebbero quindi seguire attentamente la linea che mostra la Velocità del Team.

Velocità attuale e pianificata

La Velocità attuale del Team di Sviluppo descrive il ritmo di lavoro nello Sprint completato ed è calcolata alla fine di ogni Sprint. Prende il valore della somma degli Story Points per tutte le User Stories completate. La Velocità attuale del Team di Sviluppo consente di pianificare e stimare con una certa probabilità il ritmo dei compiti futuri.

La Velocità pianificata, d’altra parte, è stimata sulla base di un valore medio della Velocità attuale. Richiede l’assunzione di nessun cambiamento nel Team di Sviluppo. È uno strumento interno importante per il Team di Sviluppo, che, basandosi su di essa, può valutare se la cooperazione nel Team sta andando bene e se il ritmo di lavoro viene mantenuto.

La Velocità pianificata consente anche al Product Owner di prevedere il tempo di esecuzione delle User Stories ben definite programmate per l’esecuzione nei successivi Sprint. Questo consente una gestione più efficiente del Product Backlog, di cui abbiamo scritto in questo articolo. Tuttavia, la pratica di applicare la Velocità pianificata per stimare le durate dei progetti non è così semplice.

Difficoltà e rischi associati alla Velocità in Scrum

La Velocità in Scrum viene spesso data troppa importanza senza considerare i seguenti fattori:

• stimare interi più grandi o l’intero progetto – mentre il Team di Sviluppo può stimare con precisione il numero di Story Points da assegnare a un compito specifico, è molto difficile o impossibile descrivere interi più grandi per l’implementazione futura in queste unità
• cambiamenti nel progetto – qualsiasi cambiamento nel progetto significa potenzialmente un cambiamento nel numero di Story Points necessari per raggiungere l’Obiettivo del Prodotto. Potrebbe anche essere che i compiti già completati debbano essere modificati o addirittura non utilizzati nella versione finale del Prodotto
• eventi imprevisti – prevedere il ritmo dei progetti futuri basandosi su quelli già completati, cioè tradurre la Velocità attuale in Velocità Pianificata, può portare a stime accurate. Tuttavia, ogni progetto ha le sue peculiarità e una previsione accurata basata sulla storia è solitamente impossibile.

Riepilogo

Utilizzare la Velocità come metrica per valutare l’efficacia del Team di Sviluppo può causare un degrado della sua affidabilità. Può anche degradare la qualità delle stime, di cui abbiamo scritto in modo più dettagliato in questo articolo. Dopotutto, per ottenere i migliori risultati possibili nelle metriche, il Team di Sviluppo potrebbe sovrastimare l’intensità lavorativa dei compiti per aumentare la Velocità. Questo è dannoso poiché il team stesso perde poi informazioni preziose per apportare miglioramenti e pianificare i propri compiti in modo più accurato.

La Velocità in Scrum è utile principalmente come misura interna utilizzata dal Team di Sviluppo per valutare il ritmo del proprio lavoro. Questo perché consente di determinare quanti compiti è in grado di completare durante un singolo Sprint.

La Velocità nelle mani del Product Owner diventa uno strumento utile per stimare la scadenza per compiti più grandi.

Tuttavia, i maggiori rischi sono associati all’uso della Velocità come metrica per valutare il Team di Sviluppo. Questo perché può portare a un abbassamento della sua credibilità e persino a una sovrastima deliberata del suo valore per migliorare la valutazione esterna del lavoro del Team Scrum.

Se ti piace il nostro contenuto, unisciti alla nostra comunità di api laboriose su Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.