Cinque metriche KPI Agile che non disprezzerai
Le statistiche e i grafici sono strumenti potenti. Usateli sempre, cari esperti di Agile... usateli sempre.
Scarica il modello di report di progetto gratuito
Semplifica la reportistica dei progetti con report coerenti e dettagliati per avere una panoramica completa dei tuoi progetti.
PUNTI CHIAVE
Metriche Agile come grafico burn-down dello sprint, velocity, durata ciclo e diagrammi di flusso cumulativi aiutano i team a monitorare lo stato di avanzamento e ottimizzare la consegna.
Queste metriche forniscono informazioni sulle prestazioni del team, sui colli di bottiglia e sulle previsioni per gli sprint futuri.
La revisione periodica delle metriche è alla base del miglioramento continuo e di un processo decisionale basato sui dati.
Incorpora le metriche Agile nelle retrospettive per riconoscere le tendenze e perfezionare il flusso di lavoro del team in modo da conseguire risultati migliori.
Le metriche costituiscono un argomento delicato.
Da un lato, abbiamo tutti lavorato a un progetto in cui non venivano tracciati dati di alcun tipo ed era difficile capire se si era sulla buona strada verso il rilascio o se l'efficienza aumentava man mano che il progetto andava avanti. D'altra parte, molti di noi hanno avuto la sfortuna di partecipare a progetti in cui le statistiche venivano utilizzate come arma, mettendo i team gli uni contro gli altri o giustificando il lavoro obbligatorio nel fine settimana. Quindi non sorprende che la maggior parte dei team abbia un rapporto di amore/odio verso le metriche.
Tuttavia, non è necessario che le cose siano così. Il monitoraggio e la condivisione di solide metriche Agile possono ridurre la confusione e far luce sull'avanzamento (e sulle battute d'arresto) del team nel corso dell'intero ciclo di sviluppo. Ecco come.
Cosa sono le metriche Agile?
Le metriche Agile sono misure quantitative che consentono di monitorare l'avanzamento, la qualità e l'efficacia di team e progetti Agile. Tra le metriche più comuni troviamo velocity, lead time, durata ciclo, grafici burn-down e diagrammi di flusso cumulativi.
Queste metriche aiutano i team a individuare i colli di bottiglia, prevedere la consegna e promuovere il miglioramento continuo. Ad esempio, il monitoraggio della velocity consente ai team di stimare quanto lavoro potranno completare negli sprint futuri, mentre il monitoraggio della durata ciclo mette in rilievo le aree in cui è possibile ottimizzare i processi.
Cos'è un KPI nell'approccio Agile?
Un KPI (Key Performance Indicator, indicatore di prestazioni chiave) nell'approccio Agile è una metrica specifica che consente di misurare il successo di un team o di un progetto rispetto a obiettivi definiti. I KPI possono includere la soddisfazione dei clienti, le percentuali di difetti o il time-to-market, a seconda di qual è l'aspetto più importante per l'organizzazione.
La selezione dei KPI giusti assicura che i team rimangano concentrati sull'offerta di valore e sul raggiungimento degli obiettivi strategici. Ad esempio, un team potrebbe monitorare il numero di bug critici risolti per ogni sprint come KPI per migliorare la qualità del prodotto e l'esperienza cliente.
Come utilizzare le metriche KPI Agile per ottimizzare la consegna
Lo stato "Completato" racconta solo una parte della storia. L'essenza consiste nel creare il prodotto giusto, al momento giusto e per il mercato giusto. Restare al passo durante l'intero programma significa raccogliere e analizzare dati pertinenti lungo il percorso. In qualsiasi programma Agile, è importante tenere traccia sia delle metriche aziendali che delle metriche Agile. Le metriche aziendali consentono di assicurarsi che la soluzione soddisfi le esigenze del mercato, mentre le metriche Agile misurano gli aspetti del processo di sviluppo.
Le metriche aziendali di un programma dovrebbero essere radicate nella sua roadmap.
Per ogni iniziativa sulla roadmap, includi diversi indicatori di prestazioni chiave (KPI) che sono mappati agli obiettivi del programma. Inoltre, includi i criteri di successo per ogni requisito di prodotto, come il tasso di adozione da parte degli utenti finali o la percentuale di codice coperta dai test automatizzati. Questi criteri di successo si inseriscono nelle metriche Agile del programma. E più i team imparano, meglio possono adattarsi ed evolversi.
Burndown sprint
I team Scrum organizzano lo sviluppo in sprint a temporizzati. All'inizio dello sprint, il team prevede quanto lavoro può completare durante uno sprint. I report burn-down dello sprint monitorano quindi il completamento del lavoro durante lo sprint. L'asse x rappresenta il tempo e l'asse y si riferisce alla mole di lavoro rimanente da completare, misurata in Story Point o in ore. L'obiettivo è quello di completare tutto il lavoro previsto entro la fine dello sprint.
Un team che rispetta in modo costante le previsioni è una pubblicità convincente di Agile nella propria organizzazione. Ma non lasciare che questo ti tenti a truccare i risultati dichiarando un articolo completo prima che lo sia davvero. Questa può sembrare una procedura vincente a breve termine, ma nel lungo periodo ostacola l'apprendimento e il miglioramento.
Anti-pattern a cui prestare attenzione
Il team finisce in anticipo sprint dopo sprint perché non si impegna abbastanza nel lavoro.
Il team non rispetta la previsione sprint dopo sprint perché si impegna troppo nel lavoro.
La linea di burn-down fa cali ripidi piuttosto che un burn-down più graduale perché il lavoro non è stato scomposto in porzioni granulari.
L'owner di prodotto aggiunge o modifica l'ambito a metà sprint.
Grafico burn-down su epic e rilasci
I grafici burn-down su epic e rilasci (o versioni) tengono traccia dell'avanzamento dello sviluppo su una mole di lavoro più ampia rispetto al burn-down dello sprint e guidano lo sviluppo sia per i team Scrum che per i team Kanban. Dal momento che uno sprint (per i team Scrum) può contenere il lavoro di più epic e versioni, è importante monitorare l'avanzamento sia dei singoli sprint che degli epic e delle versioni.
Lo "slittamento dell'ambito" consiste nell'aggiunta di ulteriori requisiti a un progetto definito in precedenza. Ad esempio, se il team sta lavorando al rilascio di un nuovo sito Web dell'azienda, lo slittamento dell'ambito può implicare la richiesta di nuove funzioni dopo che è stata definita la bozza dei requisiti iniziali. Anche se tollerare lo slittamento dell'ambito durante uno sprint è una cattiva pratica, il cambiamento dell'ambito all'interno di epic e versioni è una conseguenza naturale dello sviluppo Agile. Man mano che il team avanza nel progetto, l'owner di prodotto può decidere di aggiungere o rimuovere lavoro in base alle informazioni in suo possesso. I grafici burn-down su epic e rilasci mantengono tutti informati sugli alti e i bassi del lavoro all'interno dell'epic e della versione.
Anti-pattern a cui prestare attenzione
Il team finisce in anticipo sprint dopo sprint perché non si impegna abbastanza nel lavoro.
Il team non rispetta la previsione sprint dopo sprint perché si impegna troppo nel lavoro.
La linea di burn-down fa cali ripidi piuttosto che un burn-down più graduale perché il lavoro non è stato scomposto in porzioni granulari.
L'owner di prodotto aggiunge o modifica l'ambito a metà sprint.
Velocity
La velocity è la quantità media di lavoro che un team Scrum completa durante uno sprint, misurata in Story Point o in ore, ed è molto utile per le previsioni. L'owner di prodotto può utilizzare la velocity per prevedere la velocità con cui un team può lavorare sul backlog, perché il report tiene traccia del lavoro previsto e completato su diverse iterazioni: più iterazioni ci sono, più accurata è la previsione.
Supponiamo che l'owner di prodotto voglia completare 500 Story Point nel backlog. Sappiamo che il team di sviluppo generalmente completa 50 Story Point per iterazione. L'owner di prodotto può ragionevolmente presumere che il team avrà bisogno di 10 iterazioni (più o meno) per completare il lavoro richiesto.
È importante monitorare l'evoluzione della velocity nel tempo. I nuovi team possono aspettarsi di vedere un aumento della velocity man mano che il team ottimizza le relazioni e il processo di lavoro. I team esistenti possono monitorare la loro velocity per garantire prestazioni costanti nel tempo e possono verificare se una particolare modifica del processo ha apportato miglioramenti o meno. Una diminuzione della velocity media è di solito un segno che una parte del processo di sviluppo del team è diventata inefficiente e che dovrebbe essere quindi oggetto di discussione durante la prossima retrospettiva.
Anti-pattern a cui prestare attenzione
Il team finisce in anticipo sprint dopo sprint perché non si impegna abbastanza nel lavoro.
Il team non rispetta la previsione sprint dopo sprint perché si impegna troppo nel lavoro.
La linea di burn-down fa cali ripidi piuttosto che un burn-down più graduale perché il lavoro non è stato scomposto in porzioni granulari.
L'owner di prodotto aggiunge o modifica l'ambito a metà sprint.
La velocity di ogni team è unica. Se il team A ha una velocity di 50 e il team B ha una velocity di 75, ciò non significa che il team B abbia una produttività più elevata. Poiché la cultura della stima di ogni team è unica, lo sarà anche la velocity. Resisti alla tentazione di confrontare la velocity tra i team. Misura il livello di impegno e l'output del lavoro in base all'interpretazione degli Story Point unica di ogni team.
Grafico di controllo
I grafici di controllo si concentrano sulla durata di ciclo dei singoli ticket, ovvero sul tempo totale che intercorre tra gli stati "In corso" e "Completato". È probabile che i team con durate di ciclo più brevi abbiano una produttività più elevata e che i team con durate di ciclo coerenti su più ticket garantiscono rilasci più prevedibili. Sebbene la durata di ciclo sia una metrica primaria per i team Kanban, anche i team Scrum possono trarre vantaggio dalla durata di ciclo ottimizzata.
Misurare la durata di ciclo è un modo efficiente e flessibile per migliorare i processi di un team perché i risultati delle modifiche sono percepibili quasi subito e consentono ai team di apportare ulteriori modifiche immediatamente. L'obiettivo finale è quello di avere una durata di ciclo costante e breve, indipendentemente dal tipo di lavoro (nuova funzione, debito tecnico ecc.).
Anti-pattern a cui prestare attenzione
Il team finisce in anticipo sprint dopo sprint perché non si impegna abbastanza nel lavoro.
Il team non rispetta la previsione sprint dopo sprint perché si impegna troppo nel lavoro.
La linea di burn-down fa cali ripidi piuttosto che un burn-down più graduale perché il lavoro non è stato scomposto in porzioni granulari.
L'owner di prodotto aggiunge o modifica l'ambito a metà sprint.
Diagramma di flusso cumulativo
Il diagramma di flusso cumulativo dovrebbe apparire più o meno uniforme da sinistra a destra. Bolle o spazi vuoti di un colore qualsiasi indicano carenze e colli di bottiglia, quindi quando vedi uno di questi elementi, cerca dei modi per rendere omogenee le bande di colore sul grafico.
Anti-pattern a cui prestare attenzione
Il team finisce in anticipo sprint dopo sprint perché non si impegna abbastanza nel lavoro.
Il team non rispetta la previsione sprint dopo sprint perché si impegna troppo nel lavoro.
La linea di burn-down fa cali ripidi piuttosto che un burn-down più graduale perché il lavoro non è stato scomposto in porzioni granulari.
L'owner di prodotto aggiunge o modifica l'ambito a metà sprint.
Altre metriche Agile
Le metriche valide non si limitano ai report descritti sopra. Ad esempio, la qualità è una metrica importante per i team Agile e ci sono una serie di metriche tradizionali che possono essere applicate allo sviluppo Agile:
Quanti difetti sono stati rilevati?
durante lo sviluppo?
dopo il rilascio ai clienti?
da parte di persone esterne al team?
Quanti difetti sono rinviati a un rilascio futuro?
Quante richieste di assistenza clienti vengono ricevute?
Qual è la percentuale di copertura dei test automatizzati?
I team Agile devono considerare anche la frequenza di rilascio e la velocità di consegna. Alla fine di ogni sprint, il team dovrebbe rilasciare il software nell'ambiente di produzione. Quante volte ciò succede davvero? La maggior parte delle build di rilascio viene rilasciata? Allo stesso modo, quanto tempo impiega il team a rilasciare una correzione di emergenza nell'ambiente di produzione? Il rilascio è agevole per il team o richiede dei salti mortali?
Trova approfondimenti nel contesto
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.
Gli approfondimenti forniscono un'istantanea visiva delle seguenti metriche:
Avanzamento dello sprint
Ripartizione per tipologia ticket
Commit dello sprint
Frequenza di distribuzione
Durata ciclo
Usa queste metriche per ottimizzare continuamente le prestazioni del team. Scopri di più sugli approfondimenti.
Come si misura la buona riuscita di un progetto Agile?
La buona riuscita di un progetto Agile si misura valutando sia le metriche quantitative sia i risultati qualitativi, come l'offerta di valore ai clienti, il raggiungimento degli obiettivi aziendali e la promozione della collaborazione in team. Tra gli indicatori chiave ci sono la puntualità delle consegne, la soddisfazione degli stakeholder e la capacità di adattarsi ai cambiamenti.
Per valutare le prestazioni, i team spesso utilizzano una combinazione di metriche come la velocity, il feedback dei clienti e l'impatto sull'azienda. Ad esempio, un progetto che ha come risultato finale un prodotto di alta qualità, realizzato entro i tempi previsti e che riceve feedback positivi dagli utenti verrebbe considerato di successo in un contesto Agile.
In conclusione...
Le metriche Agile e i KPI sono solo una parte del processo di creazione della cultura di un team. Forniscono approfondimenti quantitativi sulle prestazioni del team e obiettivi misurabili per quest'ultimo. Sebbene siano importanti, non bisogna esserne ossessionati. Ascoltare il feedback del team durante le retrospettive è altrettanto importante per alimentare la fiducia in tutto il team, la qualità del prodotto e la velocità di sviluppo nel processo di rilascio. Usa il feedback quantitativo e qualitativo per guidare il cambiamento.
Risorse correlate
Consigliata per te
Modelli Jira già pronti
Sfoglia la nostra raccolta di modelli Jira personalizzati per vari team, reparti e flussi di lavoro.
Un'introduzione completa a Jira
Usa questa guida dettagliata per scoprire le funzionalità essenziali e le best practice che ti aiutano a massimizzare la produttività.
Comprendere le nozioni di base di Git
Questa guida relativa a Git può essere utilizzata da tutti, dai principianti agli utenti più esperti, per imparare le basi attraverso utili tutorial e suggerimenti.