Guida Scrum | 11. Statistiche e metriche che il Scrum Master dovrebbe monitorare

Perché il Scrum Master ha bisogno di statistiche e metriche? Prima di tutto, 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 influenzano il Development Team. Cioè, come plasmano l’esperienza utente (UX) dei dipendenti. Quindi, in questo articolo, introduciamo le statistiche e le metriche che il Scrum Master dovrebbe monitorare.

Statistiche e metriche importanti per il Scrum Master – indice dei contenuti:

1. Misurare i risultati del lavoro del Development Team
2. Monitorare l’esperienza utente dei dipendenti Sviluppatori
3. Riepilogo

Misurare i risultati del lavoro del Development Team

Le statistiche e le metriche più comunemente utilizzate che il Scrum Master dovrebbe monitorare sono quelle che descrivono il ritmo e il flusso dell’esecuzione dei compiti. Questi sono il Burnup Chart, il Burnup Chart e il Cumulative Flow Chart. Queste misure riguardano sia lo sviluppo del prodotto che l’efficacia del team. Ognuna consente di affrontare queste questioni da un angolo diverso, quindi è una buona idea mostrarle insieme. Sono strumenti utili per valutare i progressi su scale diverse, durante uno Sprint così come nell’intero processo di sviluppo del prodotto.

Burndown Chart

Il burndown chart mostra al Scrum Master e al Development Team quanto lavoro è stato fatto e quanto ne resta da fare. L’asse X mostra il tempo rimanente per completare il lavoro. L’asse Y mostra la quantità di lavoro che deve ancora essere completata e che era pianificata nel Sprint Backlog o nel Product Backlog.

Questo grafico aiuta anche a determinare la Velocità del Development Team, 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 al Scrum Master di non solo vedere quanto efficientemente sta lavorando il team. Aiuta anche a rispondere a domande:

• Quale parte del lavoro è già stata completata?
• Quanti compiti rimangono da completare?
• Quanto tempo ci vorrà per sviluppare il Prodotto?

Quando si utilizza il Burndown Chart, il Scrum Master deve tenere a mente che non è l’unico strumento per valutare statisticamente i progressi del team. Funziona meglio per progetti in cui l’ambito di lavoro è fisso e noto. Non funziona bene con la creazione di soluzioni molto innovative con un nuovo Cliente. In tal caso, la quantità di lavoro da svolgere nell’intero progetto – cioè il contenuto del Product Backlog – può cambiare significativamente durante il progetto, rendendo difficile l’uso del Burndown Chart.

Burnup chart

Il Burnup Chart è l’opposto del Burndown chart discusso sopra. Anche qui, l’asse Y mostra la quantità di lavoro rimanente da fare. L’asse X, d’altra parte, mostra il tempo di completamento espresso sia in numero di Sprints che in date.

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

Il Burnup Chart è anche uno strumento di pianificazione che diventa più efficace nel tempo. Fornisce risposte alla domanda su quanto lavoro si stima che il Development Team svolgerà nel prossimo Sprint.

Cumulative Flow Diagram

Il terzo tipo di diagramma che è molto fruttuoso nel lavoro del Scrum Master con il Development Team è il Cumulative Flow Diagram. Presenta l’analisi di quanto è stabile il ritmo e la produttività del Development Team. La disposizione dei suoi assi è la stessa del Burnup Chart, quindi è spesso definito come la sua versione più complessa.

Tuttavia, il Cumulative Flow Diagram non serve solo a determinare il numero di compiti completati in un dato periodo di tempo. Tiene anche conto del numero di compiti che sono in attesa in coda per l’esecuzione. Grazie a questo, consente di diagnosticare i cosiddetti “collo di bottiglia” – momenti del processo che rallentano la creazione di un prodotto.

Questa caratteristica diagnostica lo rende uno degli strumenti più utili nelle mani del Scrum Master. Questo perché consente di riorganizzare il lavoro in modo da distribuire diversamente le forze del Development Team e evitare tempi morti.

Monitorare l’esperienza utente dei dipendenti Sviluppatori

La manutenzione e l’analisi regolari e meticolose delle statistiche sono una parte essenziale del lavoro efficace di un Scrum Master. Tuttavia, deve tenere a mente prima di tutto l’esperienza utente dei dipendenti degli sviluppatori, cioè il modo in cui percepiscono il lavoro nel Scrum Team. Tuttavia, non è la qualità delle metriche a decidere, ma il modo in cui il Scrum Master le utilizza.

Se le statistiche sono mantenute in conformità con i principi dello 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 premiarli per ottimi risultati. Tuttavia, le statistiche possono funzionare come uno strumento per esercitare pressione sul Development Team. Allora le loro indicazioni diventano un generatore di accuse e risentimenti. Possono contribuire a deteriorare il morale del team e rovinare le pratiche di lavoro di squadra.

Il secondo fattore importante dell’esperienza dei dipendenti degli Sviluppatori, di cui il Scrum Master che lavora con strumenti statistici deve prendersi cura, è il modo di gestire il loro tempo. Questo perché il Scrum Master deve avere abbastanza tempo per prendersi cura del Development Team. Per questo motivo, in caso di un grande progetto, è opportuno considerare l’inclusione di una persona aggiuntiva nel Scrum Team. Questa persona agirà come project manager e si occuperà delle metriche. Grazie a questo, solleverà il Scrum Master – e in parte il Product Owner – dai compiti che lo distraggono dal lavorare con il Development Team.

Statistiche e metriche – riepilogo

Il Scrum Master dovrebbe tenere traccia delle statistiche di base che descrivono il lavoro del Development Team. La loro interpretazione abile aumenta la possibilità di individuare rapidamente problemi nel lavoro del Team e reagire ad essi. Tuttavia, più importante che mantenere i grafici è ciò che il Scrum Master fa con essi. Non dovrebbero trattare le metriche come uno strumento per valutare il Team, ma piuttosto considerarle come un aiuto utile per motivare il Team e diagnosticare il proprio modo di lavorare. Questo perché le metriche saranno utili solo se aiutano a facilitare i processi di miglioramento del Team e del Prodotto.

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