Riepilogo: le metriche Scrum sono punti dati specifici che i team Scrum monitorano e utilizzano per migliorare l'efficienza e l'efficacia. I team Scrum usano le metriche per informare il processo decisionale e diventare più efficienti nella pianificazione e nell'esecuzione, ma anche per fissare obiettivi e piani di miglioramento.
"Non puoi migliorare ciò che non puoi misurare", sostiene Peter Drucker, famoso esperto di strategie aziendali. Questa affermazione, sebbene non possa essere applicata a ogni aspetto della vita, è valida per i team che adottano pratiche Agile Scrum. Sfruttando determinate metriche, i team Scrum possono regolare, orientare e perfezionare l'efficacia del team.
Che cos'è Scrum?
Scrum è un framework Agile e un modo di lavorare che aiuta i team a gestire problemi complessi e sviluppare in modo iterativo soluzioni basate su un obiettivo. Il modo di lavorare Scrum è caratterizzato dallo sprint, vale a dire un breve periodo di tempo in cui un team Scrum lavora per completare una determinata quantità di lavoro.
In virtù della loro flessibilità, i framework Agile come Scrum non vengono più utilizzati esclusivamente dai team orientati alla tecnologia, ma anche da quelli che si occupano di assistenza, progettazione, marketing e non solo. Per questo motivo, le metriche Scrum sono sempre più importanti per misurare le prestazioni e l'efficacia dei team.
Cosa sono le metriche Scrum?
Le metriche Scrum sono punti dati specifici che i team Scrum possono utilizzare per migliorare l'efficienza e l'efficacia. Una volta che sono state definite, comprese e implementate, le metriche Scrum possono diventare approfondimenti utili per guidare e migliorare il percorso Agile di un team.
I team Scrum utilizzano le metriche per informare il processo decisionale e diventare più efficienti nella pianificazione e nell'esecuzione. Possono essere utilizzate anche per stabilire una baseline sullo status quo e fissare obiettivi e piani di miglioramento. In questo caso, non esiste un criterio standard del settore per poter effettuare confronti con il presente. Il motivo è che confrontare una serie di punti dati senza contesto è come confrontare mele e ostriche. Ciascun team è unico e diverso per dimensioni, tecnologie utilizzate, tipo di lavoro svolto e così via.
Ogni team deve concordare una serie di metriche per tracciare e definire il loro utilizzo. Non si tratta di uno sforzo individuale, né tantomeno di qualcosa che la leadership o la direzione può definire e applicare per conto dei team.
Perché hai bisogno di metriche Scrum?
Le metriche Scrum possono aiutare i team a stabilire i benchmark e guidare la direzione del lavoro. Pertanto, queste metriche sono utili sia per i team consolidati che per quelli appena creati.
Il monitoraggio delle metriche Scrum aiuta anche a dare visibilità a svariate dimensioni dell'efficacia di un team: ad esempio, la velocity, la capacità, la prevedibilità nella consegna o la qualità del prodotto di un team. Le metriche chiave possono rafforzare la consapevolezza delle prestazioni del team e stimolare l'azione a cambiare e migliorare. Inoltre, possono essere utili anche per valutare la felicità e la soddisfazione del team nel tempo.
Spesso molti team Agile cedono alla tentazione di affidarsi a sensazioni o intuizioni per farsi un'idea delle prestazioni di un team. Quali che siano le ragioni pratiche alla base di questa abitudine, si tratta comunque di un'enorme opportunità mancata.
Le metriche Scrum possono essere usate come indicatori di prestazioni chiave (KPI - Key Performance Indicators)?
Sì e no. Le metriche Scrum possono essere usate per configurare gli indicatori di prestazioni chiave (KPI), ma bisogna considerare il tipo e l'ambito del lavoro. Le metriche Scrum da sole non possono misurare il valore per il cliente né mostrare se il team ha consegnato quello che doveva. Per un team Agile, i KPI dovrebbero mostrare con quanta efficacia il team supporti le priorità aziendali.
Quando si misurano le prestazioni di un team Scrum, bisognerebbe considerare altre metriche che non rientrano tra quelle Scrum, ad esempio:
- Ritorno sull'investimento (ROI) per un'azienda: le aziende misurano questo valore in modi diversi a seconda degli obiettivi, per esempio la crescita dei ricavi, gli utenti attivi mensili (MAU) e altro ancora.
- Soddisfazione del cliente: le metriche dei sondaggi come il Net Promoter Score (NPS) e il Customer Satisfaction Score (CSAT) possono aiutare a monitorare il successo di un progetto. Registrare metriche di soddisfazione dei clienti costanti per ogni rilascio è importante per mostrare il valore di un team Scrum per i clienti.
- Soddisfazione del team: chiedendo a ciascun membro quale sia il proprio livello di motivazione rispetto al progetto e di coinvolgimento con il team, puoi individuare problemi come il ricambio del personale, l'attrito e gli sviluppatori insoddisfatti.
Eventi Scrum chiave e metriche da controllare
La metodologia Agile Scrum definisce diversi eventi ricorrenti (sprint, pianificazione sprint, Scrum quotidiano, revisione dello sprint, retrospettiva sprint), ma questi non forniscono alcuna garanzia di avanzamento o successo. Tuttavia, ciascuno di essi consente ai membri del team di analizzare e adattare il proprio modo di lavorare.
Pianificazione dello sprint
All'inizio di uno sprint, viene organizzata una riunione di pianificazione dello sprint in cui un team suddivide le descrizioni delle story in task dettagliati. Questa operazione fornisce una stima del lavoro da produrre durante lo sprint. Sono molteplici i punti dati che possono rendere la pianificazione dello sprint del tuo team più efficiente, ad esempio gli obiettivi dello sprint, la velocity attuale del team, la capacità del team e il tipo di lavoro. Allo scopo di guidare la nostra pianificazione dello sprint, utilizziamo un modello di riunione di pianificazione dello sprint.
Obiettivi dello sprint
Gli obiettivi dello sprint aiutano il team a decidere cosa realizzare in uno sprint, portare coesione negli elementi e stabilire le priorità. Spesso sono legati a un risultato più grande che può essere raggiunto attraverso più sprint. La priorità degli obiettivi dello sprint dovrebbe basarsi sul loro impatto su tale risultato. Un team veramente efficace esaminerà periodicamente gli obiettivi e le relative priorità per definire la strategia con cui ordinare e suddividere gli sforzi di progettazione.
Velocity del team
La quantità di tempo che un team può dedicare a uno sprint dipende fondamentalmente dalla velocity, ovvero la quantità di lavoro che può svolgere in un determinato periodo di tempo, e dalla capacità, ovvero la sua disponibilità. Un grafico della velocity, come quello che usiamo in Jira, mostra la quantità di valore fornito durante uno sprint. Questo ci aiuta a prevedere il volume di lavoro di cui un team può farsi carico per gli sprint futuri. La velocity di un team può essere compresa solo dopo aver eseguito alcuni sprint insieme come team. Nel corso del tempo, la velocity si stabilizzerà grazie alla collaborazione tra i membri del team: questo comporterà non solo un incremento delle tecnologie utilizzate, ma anche la comprensione delle competenze specifiche di ciascun membro e di come lavorare in team.
Di seguito è riportato un esempio di grafico della velocity con: (1) statistica di stima basata sugli Story Point, (2) impegno, vale a dire una stima di tutti i ticket nello sprint, (3) stime completate e (4) sprint completati.
Capacità del team
Non dovrebbe essere una sorpresa il fatto che la quantità di lavoro che un team può completare in uno sprint si basi sulla sua capacità e disponibilità. Una velocity stabile non significherà nulla se metà del tuo team è in vacanza. Un modo per pianificare la capacità è raccogliere la disponibilità di ogni membro del team a pochi sprint di distanza e aggiungere questa somma per ottenere una percentuale della capacità totale. Dal momento che le modifiche o le emergenze dell'ultimo minuto possono capitare a chiunque, è consigliabile anche lasciare un margine del 10% nell'impegno da dedicare allo sprint per evitare carichi di lavoro eccessivi e risultati inferiori alle aspettative.
Tipo di lavoro
Quando il backlog dello sprint è un mix in continua crescita di lavoro sulle funzioni, correzioni di bug e debito tecnico, diventa difficile vedere dove il tuo team sta dedicando tempo allo sprint. I bug o i debiti tecnici possono intrufolarsi nel tuo sprint, soprattutto se il team di sviluppo tiene particolarmente alla qualità. Tuttavia, se un team non è sufficientemente attento, può capitare che dopo lo sprint si domandi il motivo per cui il valore fornito al cliente sia inferiore alle aspettative.
Presta attenzione al lavoro che sta svolgendo il tuo team controllando la suddivisione dei diversi tipi di lavoro durante la pianificazione dello sprint. In questo caso, anche se trovi molti debiti tecnici e lavori di qualità nel backlog, puoi risolvere il problema strategicamente programmando uno sprint del debito tecnico o alzando il livello del controllo di qualità.
Riunioni stand-up (o Scrum quotidiani)
Le riunioni stand-up, o Scrum quotidiani, sono brevi riunioni organizzate giornalmente in cui i membri del team controllano il proprio lavoro. Per i team Scrum efficaci, le riunioni stand-up non si limitano a fornire aggiornamenti sui progressi di ciascuna persona nella propria lista delle cose da fare: costituiscono un'opportunità per controllare i progressi nello sprint di un team e riallineare le priorità, con lo scopo di prendere decisioni quotidiane più o meno grandi che possono avere un impatto significativo sul risultato di uno sprint.
A tal proposito, possono tornare utili i seguenti dati e le seguenti metriche:
Avanzamento verso gli obiettivi dello sprint
Sebbene i membri del team possano essere chiari sullo stato e sull'avanzamento del loro lavoro, può capitare di perdere di vista l'avanzamento complessivo verso gli obiettivi collettivi dello sprint. Per questo motivo, è importante preparare una lista degli obiettivi dello sprint durante una riunione stand-up che verrà controllata dall'intero team.
Considera questa come un'opportunità per capire insieme se il team sia ancora in carreggiata. Se la risposta è no, qual è il motivo e cosa si può fare a riguardo? Se non vi è una soluzione, è importante comunicarlo agli stakeholder principali affinché tutti siano sulla stessa pagina.
Burndown sprint
Per comprendere meglio l'avanzamento di un team, il tuo team dovrebbe fornire una breve panoramica dello sprint con un grafico burn-down dello sprint. Questo tipo di grafico monitora il completamento del lavoro durante uno sprint confrontando il tempo e la quantità di lavoro da completare, misurati in Story Point o in ore. Aiuta a prevedere la capacità di un team di completare il lavoro nel tempo stabilito e monitorare lo scope creep. Se un grafico burn-down presenta una flessione netta, il motivo potrebbe essere una stima imprecisa del lavoro.
Quello che segue è il grafico burn-down di uno sprint in Jira, con (1) la statistica di stima, (2) i valori rimanenti che rappresentano la quantità totale di lavoro rimanente nello sprint e (3) una linea guida che mostra dove dovrebbe trovarsi approssimativamente il tuo team.
Distribuzione del carico di lavoro
Un elemento che il team non dovrebbe mai perdere di vista è la quantità di lavoro per ogni membro. Soprattutto nella cultura del lavoro da remoto, è difficile capire quanto lavoro abbia ciascuno. Se non hai modo di scoprirlo, potrebbe capitare che alcuni membri del tuo team ricevano un carico di lavoro eccessivo. Una riunione stand-up è un luogo in cui i membri del team possono chiedersi supporto e aiuto vicendevolmente; può anche essere un luogo in cui modificare il carico di lavoro di ciascuno per raggiungere in modo più efficace gli obiettivi dello sprint.
Se utilizzi questa metrica con il tuo team, ricorda di non trasformarla in un'arma. Se la sfrutti per misurare la produttività di ciascuna persona, potresti finire per scoraggiare il tuo team. Crea piuttosto un ambiente sicuro in cui tutti possano parlare liberamente della quantità di lavoro di cui devono occuparsi e delle aree in cui hanno bisogno di aiuto.
Trova approfondimenti nel contesto
Una volta che hai stabilito la cadenza degli eventi Scrum, è importante utilizzare continuamente le metriche per ottimizzare le prestazioni. Gli approfondimenti sono un ottimo strumento che i team possono usare per accedere alle metriche quando ne hanno bisogno: durante la pianificazione dello sprint, per un controllo durante le riunioni stand-up giornaliere o per ottimizzare il rilascio. Puoi trovare gli approfondimenti nell'angolo in alto a destra nella vista della board, del backlog e delle distribuzioni di Jira.
Retrospettiva sprint
Anche i team migliori possono trarre vantaggio dalle retrospettive sprint. Questo è il momento in cui tu e il tuo team esaminate cosa è successo nello sprint celebrando i traguardi e riflettete su cosa deve essere migliorato e perché. Naturalmente, questo è anche il luogo e il momento perfetto per rivedere le metriche chiave dello sprint, tra cui il completamento degli obiettivi dello sprint e la soddisfazione dello sprint.
Quello che segue è l'esempio di una retrospettiva del mio team in una pagina Confluence:
Completamento degli obiettivi dello sprint
Come sono state le prestazioni del tuo team rispetto agli obiettivi prefissati durante la pianificazione dello sprint? Se il tuo team ha spuntato tutti gli elementi presenti nella lista, avete fatto un ottimo lavoro! In caso contrario, cosa poteva andare meglio? Le metriche Scrum di cui abbiamo già discusso possono essere utili per valutare il successo del tuo team. Qualsiasi miglioramento nel flusso di lavoro del tuo team merita di essere celebrato; forse il tuo team ha fatto progressi più velocemente perché non ci sono stati scope creep. Per i team che mettono in atto pratiche DevOps, questo può essere anche un luogo in cui controllare le metriche DevOps principali, come la durata ciclo o la frequenza di distribuzione, e discutere i possibili miglioramenti nel processo di distribuzione che potrebbero aumentare le probabilità di completare gli obiettivi dello sprint. In questo modo, aiuterai il tuo team ad affrontare il problema ed elaborare un piano d'azione più chiaro.
Soddisfazione dello sprint
Non devi fare altro che chiedere al tuo team quanto sia soddisfatto dello sprint. Alcuni team utilizzano una scala numerica, altri feedback aneddotici o addirittura emoji e GIF. Il tuo team può riflettere sui suoi obiettivi, cercando di capire se il tipo di lavoro sia in linea con essi. È stata destinata un'eccessiva quantità di tempo ai debiti tecnici piuttosto che al completamento di una funzione?
Durante la retrospettiva, incoraggia i membri del team a parlare e chiedere aiuto, se necessario. Le retrospettive migliori sono quelle con opinioni e punti di vista diversi. La cosa importante è che, entro la fine della riunione, il team concordi pienamente sui problemi principali, sui responsabili e su un piano per approfondire le questioni chiave.
In conclusione...
Lo scopo di Scrum è aiutare i team a lavorare meglio e lo scopo delle metriche Scrum è garantire il corretto funzionamento di Scrum per i team. Quando vengono applicate le metriche Scrum, un team non dovrebbe sentirsi oppresso da esse, bensì ispirato. Non occorre tenere traccia di tutto ciò di cui abbiamo parlato in questo articolo: puoi iniziare con una o due metriche e vedere se contribuiscono a migliorare un team. D'altra parte, il tuo team Scrum potrebbe già utilizzare una pratica Scrum matura, per cui le metriche Scrum non aggiungono molto valore. Se questo è il tuo caso, ottimo lavoro! Ma non dimenticare le buone abitudini che queste metriche ti hanno aiutato a stabilire. Esegui controlli periodici per verificare la salute del tuo Scrum.
