Pratica dell'uso del Cumulative Flow nel contesto di Scrum e SAFe

In questo articolo ho intenzione di raccontare come, nella nostra pratica, applichiamo il Cumulative Flow Chart in Scrum nel processo di lavoro con il framework SAFe

Inizierò, credo, con un link a questo articolo - qui, a mio parere, è ben descritta la sua funzione nella forma standard, consiglio di studiarlo prima di leggere il mio articolo. Di seguito descriverò come l'abbiamo adattato per il processo Scrum (in origine viene utilizzato in Kanban) e quali problemi ci aiuta a risolvere lavorando per sprint.

In precedenza, nell' articolo sui Burn Down Charts ho già parlato del fatto che lì vediamo la comparsa di nuovo lavoro e il burn down di quello vecchio. Il problema del Burn Down Chart è che, a differenza del Cumulative Flow Chart, su di esso non vediamo il movimento delle User Story attraverso gli stati. Quando invece iniziamo a osservare i movimenti attraverso gli stati nel Cumulative Flow Chart, iniziamo a vedere i cambiamenti quotidiani (il Burn Down Chart può non cambiare per diversi giorni e in alcuni contesti questo può essere del tutto normale) e possiamo notare problemi più sottili.

Ecco come può apparire in dinamica (nell'immagine un diagramma costruito su dati reali).

In questo esempio vediamo quanto segue

• Nei primi 7 giorni dello sprint nel testing c'è un volume di lavoro molto ridotto e non cambia
• Dal DOR (qui è una bozza) le User Story passano al lavoro in modo abbastanza uniforme - questo è positivo.
• Come sul Burn Down, vediamo che secondo la tendenza le User Story non saranno completate entro la fine dello sprint

Queste 3 osservazioni insieme portano alla seguente conclusione. Qui chiaramente già nelle fasi iniziali (verso il secondo-terzo giorno dello sprint) lo Scrum Master avrebbe dovuto prestare attenzione al livello "Testing", che è troppo piccolo e non cambia per un tempo sufficientemente lungo (accertarsi del perché). Si può supporre che il volume di lavoro pronto per il testing non sia testabile per qualche circostanza, ma allora questo significa che i tester sono inattivi, e quindi, come minimo, vale la pena ascoltarli con più attenzione al prossimo standup.

Se parliamo della pratica di applicazione, io, ad esempio, pubblico ogni giorno nella chat del team tutte le metriche prima dello standup menzionando tutto il team.

In generale, non bisogna dimenticare che le metriche vanno comunque interpretate correttamente. Saper vedere i veri problemi sistemici se ci sono e non considerare come problemi ciò che nel vostro contesto può essere persino un segnale positivo