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

Velocity in Scrum ti aiuta a determinare la velocità con cui lo Scrum Team completa le attività. Possiamo definirlo come il numero medio di Story Point completati in uno Sprint. Velocity può anche stimare la durata di un progetto in base all'avanzamento dei lavori già completato. Tuttavia, questo ha senso solo per una squadra matura che lavora a un ritmo uniforme e costante. Dai un'occhiata a cos'è Velocity e come farlo funzionare meglio per te!

Velocity in Scrum – sommario:

1. Velocity in Scrum – Introduzione
2. Velocità effettiva e pianificata
3. Difficoltà e rischi associati a Velocity in Scrum
4. Riepilogo

Velocity in Scrum – Introduzione

La velocità è un metodo opzionale ma popolare per misurare il ritmo di uno Scrum Team. Questo perché una velocità stimata con precisione consente di prevedere, in misura ragionevole, 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" da solo utilizzando un'unità familiare, come ad esempio i Punti Storia.

La velocità del team di sviluppo è spesso presentata sotto forma di un grafico della velocità. Sull'asse X sono contrassegnati gli Sprint consecutivi. Sull'asse Y, invece, troveremo il numero di Story Point o altre unità corrispondenti che sono state completate in un determinato Sprint. Con la Velocity Chart, lo Scrum Team ottiene una visione chiara dei cambiamenti nel ritmo del proprio lavoro. Se la linea segnata sul grafico è in aumento, significa che il Team sta ottimizzando la propria efficienza o riducendo il valore dei Punti Storia. Sia lo Scrum Master che il Product Owner dovrebbero quindi seguire attentamente la linea che mostra la Velocity del Team.

Velocità effettiva e pianificata

La velocità effettiva del team di sviluppo descrive il ritmo di lavoro nello Sprint completato e viene calcolata alla fine di ogni Sprint. Prende il valore della somma dei punti storia per tutte le storie utente completate. La velocità effettiva del team di sviluppo consente di pianificare e stimare con una certa probabilità il ritmo delle attività future.

La Velocità pianificata, invece, è stimata sulla base di un valore medio della Velocità effettiva. Richiede l'assunzione di nessun cambiamento nel Team di Sviluppo. Si tratta di un importante strumento interno per il Team di Sviluppo, che, sulla base di esso, può valutare se la cooperazione nel Team sta procedendo bene e se il ritmo di lavoro viene mantenuto.

Planned Velocity consente inoltre al Product Owner di prevedere il tempo di esecuzione di User Story ben definite pianificate per l'esecuzione negli Sprint successivi. Ciò consente una gestione più efficiente del Product Backlog, di cui abbiamo parlato in questo articolo. Tuttavia, la pratica di applicare la velocità pianificata per stimare la durata dei progetti non è così semplice.

Difficoltà e rischi associati a Velocity in Scrum

Alla Velocity in Scrum viene spesso data troppa importanza senza considerare i seguenti fattori:

• stimare insiemi più grandi o l'intero progetto - mentre il Team di sviluppo può stimare con precisione il numero di Story Point da assegnare a un'attività specifica, è molto difficile o impossibile descrivere insiemi più grandi per l'implementazione futura in queste unità
• cambiamenti nel progetto : qualsiasi cambiamento nel progetto significa potenzialmente un cambiamento nel numero di Story Point necessari per raggiungere l'obiettivo del prodotto. Può anche essere che le attività già completate debbano essere modificate o addirittura non utilizzate nella versione finale del Prodotto
• eventi imprevisti : prevedere il ritmo dei progetti futuri sulla base di quelli già completati, ovvero tradurre la velocità effettiva 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

L'utilizzo di Velocity come metrica per valutare l'efficacia del team di sviluppo può causare il degrado della sua affidabilità. Può anche degradare la qualità delle stime, di cui abbiamo parlato più dettagliatamente in questo articolo. Dopotutto, per ottenere i migliori risultati possibili nelle metriche, il team di sviluppo potrebbe sovrastimare l'intensità del lavoro delle attività per aumentare la velocità. Ciò è dannoso in quanto il team stesso perde informazioni preziose per apportare miglioramenti e pianificare le proprie attività in modo più accurato.

Velocity in Scrum è utile principalmente come misura interna utilizzata dal Team di sviluppo per valutare il ritmo del proprio lavoro. Questo perché gli consente di determinare quante attività è 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 rischi maggiori sono associati all'utilizzo della velocità come metrica per la valutazione del team di sviluppo. Questo perché può portare a un abbassamento della sua credibilità e persino a una sopravvalutazione deliberata del suo valore per migliorare la valutazione esterna del lavoro dello Scrum Team.

Se ti piacciono i nostri contenuti, unisciti alla nostra indaffarata community di api su Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Autore: Caroline Becker

In qualità di Project Manager, Caroline è esperta nella ricerca di nuovi metodi per progettare i migliori flussi di lavoro e ottimizzare i processi. Le sue capacità organizzative e la capacità di lavorare sotto pressione la rendono la persona migliore per trasformare in realtà progetti complicati.

Visualizza tutti i post

Guida alla mischia:

1. Glossario di termini, ruoli e nozioni di base
2. Cos'è Scrum?
3. Valori di mischia
4. Come implementare Scrum nella tua azienda?
5. Scrum Team: cos'è e come funziona?
6. Chi è un Product Owner?
7. Gli errori più comuni del Product Owner
8. Chi è lo Scrum Master?
9. Caratteristiche di un buon Scrum Master
10. Gli errori più comuni di Scrum Master
11. Quali statistiche e metriche dovrebbe monitorare lo Scrum Master?
12. Collaborazione tra Product Owner e Scrum Master
13. Team di sviluppo in Scrum
14. Gli errori più comuni degli sviluppatori
15. Artefatti di Scrum
16. Scalare Scrum
17. Sprint arretrato
18. Cos'è il Product Backlog?
19. Cosa sono le User Story?
20. Creare la migliore User Story con INVEST
21. Gli errori di User Story più comuni
22. Criteri di accettazione della User Story
23. Stima e Punti Storia in Scrum
24. Pianificazione del poker
25. Gioco di stima della squadra
26. Incremento di definizione
27. Eventi Scrum
28. Cos'è lo Sprint in Scrum?
29. Impegni dello Scrum Team - Obiettivo del prodotto, Obiettivo dello Sprint e Definizione del completamento
30. Che cos'è un diagramma di burndown?
31. Come creare e interpretare un diagramma di burndown?
32. Vantaggi e svantaggi del diagramma di burndown
33. Tavole Kanban in Scrum e Scrumban
34. Velocity in Scrum - Velocità del Team di Sviluppo
35. Scrum quotidiano
36. Pianificazione dello sprint
37. Recensione Sprint
38. Che cos'è una retrospettiva sprint?
39. Errori comuni durante una Retrospettiva Sprint
40. Consolidamento del Product Backlog