Come calcolare i valori nel Burn Down Chart in Scrum

Dopo la pubblicazione tra gli amici del primo articolo sul Burn Down Chart, nei commenti è arrivata la seconda domanda che è stata posta: "Non è chiaro come vengono calcolati tutti questi valori". Perciò, in questo articolo cercherò di raccontare come calcoliamo i valori giornalieri sul Burn Down Chart. Come al solito, sarò felice di tutti i commenti dei colleghi se mai dicessi qualcosa di sbagliato, ma comunque voglio credere che l'argomento sia sufficientemente chiaro per me.

Ricordiamo ancora una volta come appare questo diagramma.

In questo esempio viene considerato uno sprint di 10 giorni. In esso vediamo che sono passati 2 giorni (poiché solo i primi 2 segmenti sono colorati dal grafico verde).

Vediamo anche il volume totale dello sprint - questa è la linea tratteggiata, che mostra che il volume totale dello sprint lunedì alle 10:00, martedì alle 10:00 e mercoledì alle 10:00 non è cambiato ed è pari a 17 SP (Story Points).

Secondo la metodologia Scrum, il volume totale del lavoro all'interno dello sprint non cambia durante lo sprint, perciò questa linea viene costruita spesso subito per tutto lo sprint (tutti i 10 giorni). Inoltre aiuta a valutare quanto resta da fare in modo più chiaro rispetto a se terminasse al terzo giorno nella variante attuale.

Il burn down reale (grafico verde) mostra il lavoro effettivamente rimasto. Cioè ora dal team è stato completato 1 Story Point dei 17 che è necessario completare per concludere con successo lo sprint. Come completato il più delle volte si considera un task nello stato "Done" (che cosa sia Done per ogni team, lo determina il team stesso. C'è persino un artefatto speciale che si chiama DOD - Definition Of Done - è diverso per ogni team e in esso è descritto molto precisamente che cosa significa che il task è completato e lo si può spostare nello stato "Done". Il più delle volte è "Rilasciato in produzione", ma possono esserci sfumature. In generale, secondo il grafico attuale capiamo che è stato completato il DOD solo di una storia, che il team ha stimato in 1 SP.

Il burn down ideale mostra in quale punto dovrebbe trovarsi il grafico del burn down reale nel caso di un lavoro assolutamente uniforme. Cioè al momento dovrebbero essere completati 3 SP con un lavoro assolutamente uniforme.

Sospetto che possa essere interessante capire che cosa sia lo Story Point. In sostanza, 1 SP presso un team e 1 SP presso un altro team possono nascondere dietro di sé un volume di lavoro diverso. Da noi, per esempio, ci sono team con lo stesso numero di persone, ma uno ha una capacità per lo sprint di 17 SP, e l'altro di 35 SP. E questo è normale. Il fatto è che il team stesso sceglie per sé il task di riferimento rispetto al quale stima tutti i task nei grooming (nome obsoleto - è la riunione settimanale in cui il PO porta le User Stories da stimare, e il team le stima mediante il planning poker) (in SAFe questo è il PBR - Product Backlog Refinement).

Così, possiamo avere una User Story di riferimento "Io, nel ruolo di conducente di automobile, voglio dopo aver fatto rifornimento all'automobile, avere la possibilità se necessario di ottenere una ricevuta stampata su carta". Concordare che per il nostro team vale 8 SP. E, quando il PO racconta una nuova User Story, che dobbiamo stimare, la stimiamo già rispetto al task di riferimento. Di conseguenza, la nuova può già essere stimata dal team in 5 SP, per esempio, e così via tutte le storie del backlog ricevono le proprie stime.

La capacità del team viene calcolata in base alle statistiche. Nei primi 1-2 sprint viene misurata la quantità di SP che il team chiude e viene calcolato il valore medio, su questo valore avviene la pianificazione (quando il PO seleziona i task nello sprint dal backlog per una determinata capacità).

Spero di aver descritto in modo sufficientemente chiaro come si ottengono i valori sul Burn Down Chart.