Un grafico di Burn Down è 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 informazioni preziose per l’intero Team Scrum. Leggi questo articolo per scoprire come creare e interpretare un grafico di Burn Down.
Il Team di Sviluppo dovrebbe monitorare il proprio lavoro quotidiano. Questa è la base non solo per valutare la propria efficacia, ma anche per migliorarla. E uno degli strumenti più semplici e collaudati per questo scopo è il grafico di Burn Down.
Puoi crearlo manualmente disegnando un sistema di coordinate su un pezzo di carta. Sull’asse Y devi tracciare la quantità di lavoro espressa in un’unità scelta, ad esempio, punti storia. Sull’asse X, disegna una scala che indica i giorni consecutivi dello Sprint. Disegna una linea dello sprint ideale e poi segna il numero di compiti realisticamente completati per ogni giorno. Anche se questa soluzione è affascinante e coinvolge il team, non è molto pratica. Non è nemmeno necessariamente adatta per team remoti.
Pertanto, i mezzi digitali per creare un grafico di Burn Down sono molto più comuni. Molti strumenti per registrare il lavoro sui compiti distribuiti tra i membri del Team offrono un’opzione per creare automaticamente un grafico di Burn Down. Poi, tutto ciò che un Sviluppatore deve fare è segnare l’inizio e la fine del lavoro su una particolare funzionalità del prodotto, e il loro contributo si riflette nel grafico di Burn Down.
Con gli strumenti giusti, è anche possibile ridimensionare liberamente il grafico. Questo offre un’idea della combustione non solo a livello di un dato Sprint, ma anche su scala trimestrale o dell’intero progetto.
Un fattore importante da considerare quando si sceglie uno strumento per creare un grafico di Burn Down è la sua accessibilità a tutti i membri del Team Scrum. La visibilità del grafico di Burn Down per l’intero Team di Sviluppo è un fattore motivazionale chiave. È altrettanto importante dare un’occhiata quotidiana alla linea che mostra il lavoro rimanente da fare. Parlare di burn-in durante il Daily Scrum fa riflettere gli Sviluppatori sui modi in cui lavorano e sullo stato attuale del Prodotto.
La questione della proprietà del grafico di Burn Down è piuttosto controversa. Da un lato, dovrebbe appartenere allo Scrum Master, perché è uno strumento per assicurarsi che il Team stia lavorando in modo efficiente e secondo i piani. Dall’altro, dovrebbe rimanere nelle mani del Product Owner, perché riflette i progressi verso un Obiettivo di Prodotto comunicato al Cliente. Inoltre, una terza parte che potrebbe rivendicare la sua proprietà è il Team di Sviluppo, poiché il grafico funge da strumento interno.
Il grafico di Burn Down è una metrica essenziale per valutare l’efficacia del Team di Sviluppo e viene adottato da tutti i membri del Team Scrum. Ecco perché la trasparenza e l’accessibilità sono cruciali. Tuttavia, il suo scopo è servire il Team. 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 grafico di Burn Down.
In pratica, tuttavia, il compito di aggiornare il grafico di Burn Down di solito spetta allo Scrum Master. Questo accade soprattutto all’inizio del suo lavoro con un nuovo Team di Sviluppo, quando la Velocità del Team è ancora variabile e difficile da stimare. Tuttavia, è consigliato delegare questo compito a uno degli Sviluppatori. Dopotutto, il grafico è destinato a essere una misurazione onesta e interna dei progressi del lavoro come giudicata dagli stessi Sviluppatori.
Abbiamo descritto l’aspetto del grafico di Burn Down in dettaglio in un articolo precedente. Qui ricorderemo solo che l’asse X mostra il tempo rimanente per completare il lavoro. D’altra parte, l’asse Y mostra la quantità di lavoro rimanente da fare.
Per interpretare un grafico di Burn Down, il fattore chiave non è solo il regolare tracciamento della “combustione” reale, cioè l’esecuzione dei compiti da parte del Team di Sviluppo. È altrettanto importante per il quadro il confronto con la linea di combustione ideale (linea guida).
Confrontando la linea di combustione ideale con la riduzione reale del lavoro segnata sul grafico di Burn Down, possono essere valutati due parametri molto importanti. Primo, per vedere se il lavoro continua al ritmo attuale, il Team di Sviluppo raggiungerà l’Obiettivo dello Sprint o dell’Obiettivo di Prodotto in tempo. Secondo, per avere un’idea di quando il lavoro sarà completato mantenendo il ritmo attuale. In altre parole, il grafico di Burn Down mostra il ritmo effettivo dei compiti, e la linea ideale mostra a quale ritmo il Team dovrebbe lavorare per completare i compiti.
Il grafico di Burn Down consente anche di determinare un valore chiamato Velocità del Team di Sviluppo nel lungo periodo. Dedicheremo un articolo separato a questo. Qui menzioneremo solo che è un valore determinato dalla quantità di lavoro svolto durante uno Sprint.
Grazie al fatto che il grafico di Burn Down illustra il confronto tra una linea di combustione ideale e una reale diminuzione del numero di compiti, consente di stimare il ritmo di lavoro. E così anticipare il rischio di ritardi nel progetto.
La velocità del Team è solitamente misurata in unità chiamate punti storia. Essa definisce il numero di storie utente che sono state realizzate. Queste possono richiedere quantità di lavoro molto diverse.
Per questo motivo, molti Team Scrum utilizzano una misura basata sul tempo. A seconda della scala, queste sono giorni o ore-uomo. Ogni Sviluppatore stima e poi registra la quantità di tempo speso sui propri compiti.
Un’altra opzione è adottare i compiti come unità. Queste sono unità leggermente più grandi, a cui viene assegnato un valore espresso in punti storia, o in giorni o ore-uomo. È un’unità che consente al cliente di presentare i progressi del lavoro sul prodotto in modo più chiaro.
Indipendentemente dall’unità di misura, è importante ricordare il principio di calcolo della velocità del Team di Sviluppo. In un dato giorno o Sprint, contano solo i compiti che sono stati effettivamente completati. Ciò significa che i compiti iniziati verranno conteggiati per il giorno successivo o lo Sprint successivo anche se manca solo il test finale.
Con gli strumenti di monitoraggio del team disponibili, creare un grafico di Burn Down diventa un compito facile. La questione più importante è garantire la sua coerenza, chiarezza e accessibilità a tutti i membri del Team Scrum.
Se ti piace il nostro contenuto, unisciti alla nostra comunità di api laboriose su Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.
Come Project Manager, Caroline è un'esperta nel trovare nuovi metodi per progettare i migliori flussi di lavoro e ottimizzare i processi. Le sue capacità organizzative e la sua abilità di lavorare sotto pressione temporale la rendono la persona migliore per trasformare progetti complicati in realtà.
I destinatari sempre più spesso si rivolgono ai materiali video. Le forme scritte diventano meno…
La scrittura pubblicitaria è diventata una professione estremamente popolare negli ultimi tempi. Ci sono sempre…
Hai mai la sensazione che la giornata sia troppo corta per fare tutto ciò che…
Che cos'è il software? Quali sono i tipi e i metodi di distribuzione? Rimanendo in…
Presentare e comunicare i risultati della ricerca è probabilmente una delle abilità più cruciali (e…
Sai come creare un ebook? Conosci tutti gli aspetti essenziali del processo di produzione di…