Guida Scrum | 11. Statistiche e metriche che lo Scrum Master dovrebbe tracciare

Perché lo Scrum Master ha bisogno di statistiche e metriche? In primo luogo, per verificare se i suoi metodi di lavoro sulla prevedibilità dei risultati e sul miglioramento dell'efficacia del team sono efficaci. Ma anche per tenere traccia di come le loro azioni influiscono sul team di sviluppo. Ovvero, come modellano l'esperienza utente (UX) dei dipendenti. Quindi, in questo articolo, introduciamo statistiche e metriche che lo Scrum Master dovrebbe monitorare.

Statistiche e metriche importanti per lo Scrum Master – Sommario:

1. Misurare i risultati del lavoro del Team di Sviluppo
2. Monitoraggio dell'esperienza utente dei dipendenti Sviluppatori
3. Riepilogo

Misurare i risultati del lavoro del Team di Sviluppo

Le statistiche e le metriche più comunemente utilizzate che lo Scrum Master dovrebbe monitorare sono quelle che descrivono il ritmo e il flusso di esecuzione delle attività. Questi sono il diagramma di burnup, il diagramma di burnup e il diagramma di flusso cumulativo. Questi misurano sia lo sviluppo del prodotto che l'efficacia del team. Ciascuno ti consente di affrontare questi problemi da una diversa angolazione, quindi è una buona idea mostrarli insieme. Sono strumenti utili per valutare i progressi su diverse scale, durante uno Sprint e durante l'intero processo di sviluppo del prodotto.

Grafico Burndown

Il diagramma di burndown mostra allo Scrum Master e al Team di Sviluppo quanto lavoro è stato svolto e quanto resta da fare. L'asse X mostra il tempo rimasto per completare il lavoro. L'asse Y mostra la quantità di lavoro rimanente da svolgere pianificata nello Sprint Backlog o nel Product Backlog.

Questo grafico aiuta anche a determinare la Velocità del Team di Sviluppo, a cui dedicheremo anche un articolo separato. Qui menzioneremo solo che si tratta di una quantità media di lavoro svolto durante uno Sprint.

Questo semplice strumento consente allo Scrum Master non solo di vedere l'efficienza del lavoro del team. Aiuta anche a rispondere alle domande:

• Quale parte dei lavori è già stata completata?
• Quante attività restano da completare?
• Quanto tempo ci vorrà per sviluppare il prodotto?

Quando si utilizza il Burndown Chart, lo Scrum Master deve tenere presente che non è l'unico strumento per valutare statisticamente i progressi del team. Funziona meglio per i progetti in cui l'ambito del lavoro è fisso e noto. Non funziona bene con la creazione di soluzioni molto innovative con un nuovo Cliente. Quindi la quantità di lavoro da svolgere nell'intero progetto – ovvero il contenuto del Product Backlog – può cambiare in modo significativo durante il progetto, rendendo difficile l'utilizzo del Burndown Chart.

Grafico di burnup

Il grafico Burnup è l'inverso del grafico Burndown discusso sopra. Anche in questo caso, l'asse Y mostra la quantità di lavoro rimanente da fare. L'asse X, invece, mostra il tempo di completamento espresso in numero di Sprint o in date.

Tuttavia, lo Scrum Master usa Burnup Chart per uno scopo leggermente diverso. Questo perché non solo ti aiuta a misurare i progressi del prodotto e i progressi del Team. Questa metrica valuta anche come l'ambito del lavoro in un progetto cambia nel tempo. Pertanto, funziona bene per progetti con portata variabile.

Il Burnup Chart è anche uno strumento di pianificazione che sta diventando più efficace nel tempo. Fornisce risposte alla domanda su quanto lavoro si stima che il Team di sviluppo dovrà svolgere nel prossimo Sprint.

Diagramma di flusso cumulativo

Il terzo tipo di diagramma che è molto fruttuoso nel lavoro dello Scrum Master con il Team di Sviluppo è il Diagramma di Flusso Cumulativo. Presenta l'analisi della stabilità del ritmo e della produttività del team di sviluppo. Il layout dei suoi assi è lo stesso del Burnup Chart, quindi viene spesso definito la sua versione più complessa.

Tuttavia, il diagramma di flusso cumulativo non serve solo a determinare il numero di attività completate in un determinato periodo di tempo. Tiene inoltre conto del numero di attività in attesa di esecuzione in coda. Grazie a ciò permette di diagnosticare i cosiddetti “colli di bottiglia”, momenti del processo che rallentano la realizzazione di un prodotto.

Questa caratteristica molto diagnostica lo rende una delle metriche più utili nelle mani dello Scrum Master. Questo perché permette di riorganizzare il lavoro in modo da distribuire diversamente la forza del Team di Sviluppo ed evitare tempi morti.

Monitoraggio dell'esperienza utente dei dipendenti Sviluppatori

Una regolare e meticolosa manutenzione e analisi delle statistiche è una parte essenziale del lavoro di uno Scrum Master efficace. Tuttavia, deve prima tenere a mente l'esperienza utente dei dipendenti degli sviluppatori, cioè il modo in cui percepiscono il lavoro nello Scrum Team. Tuttavia, non è la qualità delle metriche che decide, ma il modo in cui lo Scrum Master le utilizza.

Se le statistiche sono mantenute in conformità con i principi di Scrum – sono trasparenti, pubbliche e comprensibili per gli Sviluppatori coinvolti – possono essere un modo per motivare il team a lavorare in modo più efficiente o per premiarlo per ottimi risultati. Tuttavia, le statistiche possono fungere da strumento per esercitare pressione sul team di sviluppo. Allora le loro indicazioni diventano generatore di accuse e risentimenti. Possono contribuire a deteriorare il morale della squadra e rovinare le pratiche di lavoro di squadra.

Il secondo fattore importante dell'esperienza dei dipendenti degli Sviluppatori, di cui deve occuparsi lo Scrum Master che lavora con strumenti statistici, è il modo di gestire il proprio tempo. Questo perché lo Scrum Master ha bisogno di tempo a sufficienza per prendersi cura del Team di Sviluppo. Per questo, nel caso di un progetto di grandi dimensioni, vale la pena considerare l'inserimento di una persona in più nello Scrum Team. Agirà come project manager e si occuperà delle metriche. Grazie a ciò, solleverà lo Scrum Master – e in una certa misura il Product Owner – dai compiti che lo distraggono dal lavorare con il Team di Sviluppo.

Statistiche e metriche – riepilogo

Lo Scrum Master dovrebbe tenere traccia delle statistiche di base che descrivono il lavoro del Team di Sviluppo. La loro abile interpretazione aumenta le possibilità di individuare rapidamente i problemi nel lavoro del Team e di reagire ad essi. Tuttavia, più importante che tenere le classifiche è ciò che lo Scrum Master fa con esse. Non dovrebbero considerare le metriche come uno strumento per valutare il Team, ma piuttosto trattarle come un utile aiuto per motivare il Team e diagnosticare il proprio modo di fare le cose. Questo perché le metriche saranno strumenti utili solo se aiuteranno a facilitare i processi di miglioramento del Team e del Prodotto.

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

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