Guida Scrum | 32. Vantaggi e svantaggi del diagramma di burndown

Il diagramma di combustione ha molti vantaggi. È uno dei principali strumenti di misurazione in Scrum per diversi motivi. È facile da creare, ridimensionare e leggere. Tuttavia, presenta anche degli svantaggi che lo rendono non uno strumento universale. Nell'articolo di oggi, trattiamo l'argomento degli svantaggi e dei vantaggi del diagramma di burndown.

Vantaggi e svantaggi del diagramma di burndown – sommario:

1. introduzione
2. Vantaggi del grafico Burndown
3. Svantaggi del grafico Burndown
4. Riepilogo

introduzione

Abbiamo scritto di cosa si tratta, come creare e interpretare un diagramma di burndown negli articoli precedenti. Oggi ci concentreremo sui vantaggi e gli svantaggi del diagramma di burndown. Tuttavia, la maggior parte di essi non è nascosta nel semplice grafico stesso. Piuttosto, sono legati ai modi di utilizzare il diagramma di burndown per motivare il Team di sviluppo, poiché descrivono i risultati del loro lavoro e rafforzano l'auto-organizzazione.

Vantaggi del grafico Burndown

Il diagramma di masterizzazione ti consente di visualizzare lo stato di avanzamento del tuo progetto. La sua leggibilità e semplicità lo rendono così popolare. Ecco perché è una buona idea che Burn Chart non sia solo una metrica costantemente aggiornata nascosta in uno strumento di gestione dei progetti digitali. Se possibile, vale la pena renderlo un punto di riferimento per il Team di Sviluppo visibile nel luogo di lavoro fisico. Che si tratti di una visualizzazione su schermo o di uno schizzo disegnato a mano.

Motiva il team di sviluppo

La trasparenza del diagramma di masterizzazione può renderlo uno strumento per motivare il team di sviluppo a lavorare in modo efficiente. Raggiungere il punto “zero” in ogni Sprint può diventare un obiettivo ambizioso del Team, per il quale vengono assegnate ricompense – secondo i principi della business gamification.

La visibilità di un diagramma di burndown aggiornato e mantenuto in modo interessante può anche rafforzare lo spirito di cooperazione e di auto-organizzazione. Dopotutto, la metrica è una misura del lavoro di squadra. Non mostra esattamente chi ha completato o meno le attività pianificate, solo i risultati raggiunti.

Misura il lavoro effettivo svolto

Gli sviluppatori decidono quante attività eseguiranno in un determinato Sprint. Più il Team è esperto, più accuratamente dovrebbe prevedere le proprie azioni. E il grafico di bur-down riflette il reale progresso dello Sprint.

Pertanto, il vantaggio del diagramma di combustione non è tanto quello di misurare la quantità oggettiva di lavoro svolto, ma il rapporto tra attività pianificate e completate. Pertanto, gli sviluppatori imparano gradualmente come pianificarli e possono stimare le proprie capacità in modo più accurato ed eliminare gli errori ripetitivi.

Si accoppia con altri strumenti

Uno dei vantaggi significativi del diagramma di burndown riguarda la sua versatilità nella combinazione con altri strumenti. I seguenti strumenti possono essere applicati a:

• analizzare il lavoro del Team di sviluppo
• visualizzare lo stato di avanzamento dei lavori sul Prodotto
• stimare il budget del progetto

Ad esempio, in quest'ultimo caso, l'uso del Project Scale Burndown Chart consente di confrontare il budget pianificato ed effettivo per l'intero progetto.

Svantaggi del grafico Burndown

Nonostante tutti i vantaggi del grafico Burndown sopra delineato, può diventare fonte di confusione per il Team di sviluppo. Tuttavia, quelli che spesso chiamiamo i "difetti" del diagramma di burndown non sono dovuti a imperfezioni dello strumento stesso. I problemi delineati di seguito riguardano il modo di implementare il diagramma di burndown piuttosto che la sua progettazione. Di seguito sono riportati i difetti che possono interferire con la rappresentazione dei progressi del Team di sviluppo in questo modo.

“Il fattore umano”

I grafici non possono essere una misura assoluta dei progressi di una squadra. Sono solo strumenti da applicare in modi diversi, più o meno abili. Possiamo considerarlo come uno svantaggio (o vantaggio) non solo del grafico di burndown ma anche di altre misure delle prestazioni della squadra.

Per creare un diagramma di burndown, è necessario che altre persone inseriscano i dati. In altre parole, gli sviluppatori annotano il tempo di completamento delle attività sul grafico. Potrebbero averlo allungato o accorciato un po', o per disattenzione o per voler migliorare le cose per la squadra. Gli sviluppatori a volte dimenticano anche di registrare il proprio tempo. Oppure lascia il timer acceso. Ciò fa sì che l'orario di lavoro si estenda a diverse ore. E dopo aver scoperto l'errore, è difficile ricostruirne il vero corso.

Modifiche allo Sprint Backlog

Lo Sprint Backlog non deve essere modificato dopo l'inizio di uno Sprint. Tuttavia, in pratica, tali cambiamenti si verificano abbastanza spesso. Risultano dalle mutevoli esigenze degli Stakeholder. O problemi imprevisti che incontrano gli sviluppatori.

Questo fa sì che il grafico di burndown venga ridimensionato. Questo perché il tempo necessario per completare le attività rimane lo stesso. Tuttavia, la scala dei compiti rimanenti aumenta. Ciò può dare l'impressione fuorviante che il Team di sviluppo abbia pianificato in modo errato il lavoro da svolgere in un determinato Sprint. O che funziona troppo lentamente.

Le modifiche allo Sprint Backlog possono anche derivare da attività pianificate per il completamento troppo rapidamente. In una situazione del genere, il Team di sviluppo di solito decide di aumentare il numero di compiti. Ciò a sua volta potrebbe comportare il mancato completamento in tempo. Inoltre, possono sorgere conflitti dalla sovrapposizione di attività rimanenti dello Sprint precedente con nuove attività programmate per essere completate dagli stakeholder e dai Product Owner.

Modifiche al Product Backlog

Grandi cambiamenti nel Product Backlog possono alterare la forma del diagramma di masterizzazione. E così falsificare fortemente il quadro dello stato di avanzamento lavori e dell'efficacia del Team. Ciò accade quando vengono visualizzate nuove User Story . E quelli che sono prossimi alla fase di implementazione sono spesso suddivisi in parti più piccole. Succede anche che il Cliente rinunci ad alcune funzionalità del Prodotto.

Pertanto, quando si interpreta il diagramma di combustione, bisogna essere guidati dalla conoscenza e dall'esperienza nella valutazione delle prestazioni del Team. E tenere conto anche della variabilità del Backlog. Se il grafico non è l'unica metrica utilizzata per valutare le prestazioni, gli altri grafici ti permetteranno di avere un quadro più completo dello stato di avanzamento dei lavori.

Riepilogo

Il diagramma di burndown può contribuire in modo significativo alla motivazione del Team di Sviluppo. Questo perché fornisce una misura del lavoro reale svolto sul piano. Inoltre, la sua combinazione con altri strumenti metrici può essere una fonte di preziose conoscenze sul lavoro del Team e sulla pianificazione del prodotto.

Applicando attentamente i principi di Scrum, puoi evitare potenziali problemi con il burndown. La cosa più importante è adattare gli strumenti per mantenere il grafico seguendo il lavoro effettivo dello Scrum Team, così come ridurre al minimo le modifiche allo Sprint e al Product Backlog, di cui scriviamo di più in questo articolo.

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