Guida Scrum | 32. Vantaggi e svantaggi del Grafico di Burn Down

Il Burndown Chart ha molti vantaggi. È uno degli strumenti metrici principali in Scrum per diversi motivi. È facile da creare, scalare e leggere. Tuttavia, ha anche degli svantaggi che lo rendono non uno strumento universale. Nell’articolo di oggi, trattiamo il tema degli svantaggi e dei vantaggi del Burndown Chart.

Vantaggi e svantaggi del Burndown Chart – indice dei contenuti:

1. Introduzione
2. Vantaggi del Burndown Chart
3. Svantaggi del Burndown Chart
4. Riepilogo

Introduzione

Abbiamo scritto su cosa sia, come creare e interpretare un Burndown Chart in articoli precedenti. Oggi ci concentreremo sui vantaggi e svantaggi del Burndown Chart. Tuttavia, la maggior parte di essi non è nascosta nel semplice grafico stesso. Piuttosto, sono legati ai modi di utilizzare il Burndown Chart per motivare il Team di Sviluppo, poiché descrivono i risultati del loro lavoro e rafforzano l’auto-organizzazione.

Vantaggi del Burndown Chart

Il Burndown Chart consente di visualizzare i progressi del tuo progetto. La sua leggibilità e semplicità lo rendono così popolare. Ecco perché è una buona idea che il Burndown Chart non sia solo una metrica costantemente aggiornata nascosta in uno strumento di gestione progetti digitale. Se possibile, vale la pena farne un punto di riferimento per il Team di Sviluppo visibile nel luogo di lavoro fisico. Sia sotto forma di una visualizzazione su schermo che di uno schizzo disegnato a mano.

Motiva il Team di Sviluppo

La trasparenza del Burndown Chart 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 per il Team, per il quale vengono dati premi – secondo i principi della gamification aziendale.

La visibilità di un Burndown Chart aggiornato e mantenuto in modo interessante può anche migliorare lo spirito di cooperazione e auto-organizzazione. Dopotutto, la metrica è una misura del lavoro di squadra. Non mostra esattamente chi ha completato – o non ha completato – i compiti pianificati, solo i risultati raggiunti.

Misura il lavoro effettivamente svolto

I programmatori decidono quanti compiti svolgeranno in un dato Sprint. Più esperto è il Team, più accuratamente dovrebbe prevedere le proprie azioni. E il Burndown Chart riflette il reale progresso dello Sprint.

Quindi, il vantaggio del Burndown Chart non è tanto quello di misurare la quantità oggettiva di lavoro svolto, ma il rapporto tra compiti pianificati e completati. Così, i programmatori imparano gradualmente a pianificarli e possono stimare le proprie capacità in modo sempre più accurato ed eliminare errori ripetitivi.

Si combina con altri strumenti

Uno dei vantaggi significativi del Burndown Chart riguarda la sua versatilità nel combinarsi con altri strumenti. I seguenti strumenti possono applicarsi a:

• analizzare il lavoro del Team di Sviluppo
• visualizzare i progressi del lavoro sul Prodotto
• stimare il budget del progetto

Ad esempio, in quest’ultimo caso, l’uso del Burndown Chart della Scala di Progetto consente un confronto tra il budget pianificato e quello effettivo per l’intero progetto.

Svantaggi del Burndown Chart

Nonostante tutti i vantaggi del Burndown Chart delineati sopra, può diventare una fonte di confusione per il Team di Sviluppo. Tuttavia, ciò che chiamiamo frequentemente “difetti” del Burndown Chart non è dovuto a imperfezioni dello strumento stesso. I problemi delineati di seguito riguardano il modo di implementare il Burndown Chart piuttosto che il suo design. 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 un team. Sono solo strumenti da applicare in modi diversi, più o meno abili. Possiamo considerarlo come uno svantaggio (o vantaggio) non solo del Burndown Chart ma anche di altre misure delle prestazioni del team.

Per creare un Burndown Chart, hai bisogno di altre persone per inserire i dati. In altre parole, i programmatori annotano il tempo di completamento dei compiti sul grafico. Potrebbero averlo allungato o accorciato un po’ – sia per disattenzione che per voler migliorare le cose per il team. I programmatori a volte dimenticano anche di registrare il loro tempo. O lasciano il timer acceso. Questo causa l’estensione del tempo di lavoro a diverse ore. E dopo aver scoperto l’errore, è difficile ricostruire il suo reale corso.

Cambiamenti al Sprint Backlog

Lo Sprint Backlog non dovrebbe essere modificato dopo l’inizio di uno Sprint. Tuttavia, in pratica, tali cambiamenti si verificano abbastanza spesso. Sono il risultato di requisiti cambianti da parte degli Stakeholder. O problemi imprevisti che i programmatori incontrano.

Questo causa la scalatura del Burndown Chart. Questo perché il tempo impiegato per completare i compiti rimane lo stesso. Tuttavia, la scala dei compiti rimanenti aumenta. Questo può dare un’impressione fuorviante che il Team di Sviluppo abbia pianificato in modo errato il lavoro da svolgere in un dato Sprint. O che lavori troppo lentamente.

I cambiamenti allo Sprint Backlog possono anche derivare da compiti che erano programmati per essere completati troppo rapidamente. In una situazione del genere, il Team di Sviluppo di solito decide di aumentare il numero di compiti. Questo a sua volta può portare a non completarli in tempo. Inoltre, possono sorgere conflitti a causa della sovrapposizione di compiti rimanenti dal precedente Sprint con nuovi compiti programmati per essere completati dagli Stakeholder e dai Product Owner.

Cambiamenti al Product Backlog

Grandi cambiamenti nel Product Backlog possono compromettere la forma del Burndown Chart. E così falsificare fortemente l’immagine dei progressi lavorativi e dell’efficacia del Team. Questo accade quando compaiono nuove User Stories. E quelle che sono vicine alla fase di implementazione vengono spesso suddivise in parti più piccole. Accade anche che il Cliente rinunci ad alcune funzionalità del Prodotto.

Pertanto, quando si interpreta il Burndown Chart, bisogna essere guidati da conoscenza ed esperienza nella valutazione delle prestazioni del Team. E anche tenere conto della variabilità del Backlog. Se il grafico non è l’unica metrica utilizzata per valutare le prestazioni, gli altri grafici permetteranno di vedere un quadro più completo dei progressi del lavoro.

Riepilogo

Il Burndown Chart può contribuire significativamente a motivare il 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 informazioni sul lavoro del Team e sulla pianificazione del Prodotto.

Applicando attentamente i principi di Scrum, puoi evitare potenziali problemi con il Burndown Chart. La cosa più importante è adattare gli strumenti per mantenere il grafico seguendo il reale lavoro del Team Scrum, così come minimizzare i cambiamenti allo Sprint e al Product Backlog, di cui scriviamo di più in questo articolo.

Se ti piace il nostro contenuto, unisciti alla nostra comunità di api laboriose su Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.