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.
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.
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:
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.
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.
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.
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.
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.
Come Project Manager, Caroline è un'esperta nel trovare nuovi metodi per progettare i migliori flussi di lavoro e ottimizzare i processi. Le sue capacità organizzative e la sua abilità di lavorare sotto pressione temporale la rendono la persona migliore per trasformare progetti complicati in realtà.
Diverse eventi più piccoli compongono uno Sprint in Scrum. Gli Sprint, a loro volta, formano…
I destinatari sempre più spesso si rivolgono ai materiali video. Le forme scritte diventano meno…
La scrittura pubblicitaria è diventata una professione estremamente popolare negli ultimi tempi. Ci sono sempre…
Hai mai la sensazione che la giornata sia troppo corta per fare tutto ciò che…
Che cos'è il software? Quali sono i tipi e i metodi di distribuzione? Rimanendo in…
Presentare e comunicare i risultati della ricerca è probabilmente una delle abilità più cruciali (e…