Guida Scrum | 31. Come creare e interpretare un diagramma di burndown?

Un diagramma di burndown è relativamente facile da creare. Ci sono molti strumenti disponibili per generarlo dal lavoro registrato dai membri del Team di sviluppo. Nonostante la sua semplicità, la sua interpretazione può fornire preziose informazioni per l'intero Scrum Team. Leggi questo articolo per scoprire come creare e interpretare un diagramma di burndown.

Come creare e interpretare un diagramma di burndown? - sommario:

1. Come creare un diagramma di burndown?
2. Chi è responsabile del diagramma di burndown?
3. Come interpretare un diagramma di burndown?
4. Grafico di burndown reale e ideale
5. Selezione dell'unità di misura
6. Riepilogo

Come creare un diagramma di burndown?

Il team di sviluppo dovrebbe monitorare il proprio lavoro quotidiano. Questa è la base non solo per valutarne l'efficacia ma anche per migliorarla. E uno degli strumenti più semplici e collaudati per questo scopo è il diagramma di masterizzazione.

Puoi crearlo manualmente disegnando un sistema di coordinate su un pezzo di carta. Sull'asse Y è necessario tracciare la quantità di lavoro espressa in un'unità scelta, ad esempio, story point. Sull'asse X, traccia una scala indicante i giorni consecutivi dello Sprint. Disegna una linea dello sprint ideale, quindi segna il numero di attività realisticamente completate per ogni giorno. Sebbene questa soluzione sia affascinante e coinvolga il team, non è molto pratica. Inoltre, non è necessariamente adatto per i team remoti.

Pertanto, i mezzi digitali per creare un grafico di burndown sono molto più comuni. Molti strumenti per la registrazione del lavoro sulle attività distribuite tra i membri del team sono dotati di un'opzione per creare automaticamente un grafico di burndown. Quindi, tutto ciò che uno sviluppatore deve fare è contrassegnare l'inizio e la fine del lavoro su una particolare funzionalità del prodotto e il loro contributo si riflette nel diagramma di masterizzazione.

Con gli strumenti giusti, è anche possibile scalare liberamente il grafico. Questo dà una visione della combustione non solo a livello di un dato Sprint ma anche sulla scala di un quarto o dell'intero progetto.

Un fattore importante da considerare quando si sceglie uno strumento per creare un diagramma di burndown è la sua accessibilità a tutti i membri dello Scrum Team. La visibilità del diagramma di burndown per l'intero Team di Sviluppo è un fattore motivazionale chiave. Altrettanto importante è uno sguardo quotidiano alla linea che mostra il lavoro che resta da fare. Parlare di burn-in durante il Daily Scrum, fa riflettere gli sviluppatori sul modo in cui funzionano e sullo stato attuale del prodotto.

Chi è responsabile del diagramma di burndown?

La questione della proprietà del diagramma di combustione è alquanto controversa. Da un lato, dovrebbe appartenere allo Scrum Master, perché è uno strumento per assicurarsi che il Team lavori in modo efficiente e secondo i piani. Dall'altro, dovrebbe rimanere nelle mani del Product Owner, perché riflette il progresso verso un obiettivo del prodotto che viene comunicato al cliente. Inoltre, una terza parte a rivendicarne la proprietà è il Team di sviluppo poiché il grafico funge da strumento interno.

Il diagramma di burndown è una metrica essenziale per valutare l'efficacia del Team di Sviluppo e viene adottato da tutti i membri dello Scrum Team. Ecco perché la trasparenza e l'accessibilità sono fondamentali. Tuttavia, il suo stesso scopo è servire la squadra. Dovrebbe rafforzare la sua auto-organizzazione, migliorare la motivazione e fornire un quadro reale dello stato del lavoro sui compiti assegnati. Pertanto, in teoria, ogni membro del Team di sviluppo può aggiornare il diagramma di masterizzazione.

In pratica, però, il compito di aggiornare il burndown chart è solitamente dello Scrum Master. Questo accade soprattutto all'inizio del suo lavoro con un nuovo Team di Sviluppo quando la Team Velocity è ancora variabile e difficile da stimare. Tuttavia, si consiglia di delegare questo compito a uno degli Sviluppatori. Dopotutto, il grafico vuole essere una misurazione interna e onesta dello stato di avanzamento dei lavori, come giudicato dagli stessi Sviluppatori.

Come interpretare un diagramma di burndown?

Abbiamo descritto in dettaglio l'aspetto del grafico di burndown in un articolo precedente. Qui ti ricordiamo solo che l'asse X mostra il tempo rimasto per completare il lavoro. D'altra parte, l'asse Y mostra la quantità di lavoro rimanente da fare.

Grafico di burndown reale e ideale

Per interpretare un diagramma di burndown, il fattore chiave non è solo la regolare tracciatura della vera “combustione”, ovvero l'esecuzione dei compiti da parte del Team di Sviluppo. Altrettanto importante per l'immagine è il suo confronto con la caduta ideale della linea di combustione (linea guida).

Confrontando la linea di combustione ideale con la riduzione del lavoro nel mondo reale segnata sul diagramma di combustione, è possibile valutare due parametri molto importanti. In primo luogo, per vedere se il lavoro continua al ritmo attuale, il team di sviluppo raggiungerà l'obiettivo di sprint o l'obiettivo di prodotto in tempo. In secondo luogo, per avere un'idea di quando il lavoro sarà completato mantenendo il ritmo attuale. In altre parole, il diagramma di masterizzazione mostra il ritmo effettivo delle attività e la linea ideale mostra a quale ritmo il team dovrebbe lavorare per completare le attività.

Il grafico di masterizzazione consente inoltre di determinare un valore chiamato Development Team Velocity a lungo termine. Gli dedicheremo un articolo separato. Qui ci limiteremo a menzionare che è un valore determinato dalla quantità di lavoro svolto durante uno Sprint.

Grazie al fatto che il diagramma di combustione illustra il confronto di una linea di combustione ideale con una reale diminuzione del numero di attività, consente di stimare il ritmo di lavoro. E quindi anticipare il rischio di ritardi del progetto.

Selezione dell'unità di misura

La velocità della squadra viene solitamente misurata in unità chiamate story point. Definisce il numero di storie utente che sono state realizzate. Questi possono richiedere quantità di lavoro molto diverse.

Questo è il motivo per cui molti Scrum Team utilizzano una misura basata sul tempo. A seconda della scala, questi sono giorni o ore uomo. Ogni sviluppatore stima e quindi registra la quantità di tempo speso per le proprie attività.

Un'altra opzione è quella di adottare le attività come un'unità. Si tratta di unità leggermente più grandi, alle quali a loro volta viene assegnato un valore espresso in story point, oppure in giorni o ore uomo. È un'unità che consente al cliente di presentare in modo più chiaro lo stato di avanzamento dei lavori sul prodotto.

Indipendentemente dall'unità di misura, vale la pena ricordare il principio del calcolo della velocità del Team di sviluppo. In un determinato giorno o Sprint , contano solo le attività effettivamente completate. Significa che le attività iniziate verranno conteggiate nel giorno successivo o nello Sprint anche se manca solo il test finale.

Riepilogo

Con gli strumenti di monitoraggio del team disponibili, la creazione di un diagramma di burndown diventa un compito facile. La questione più importante è assicurarne la coerenza, la chiarezza e l'accessibilità a tutti i membri dello Scrum Team.

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

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