Praxis för tillämpning av Cumulative Flow i kontexten Scrum och SAFe

I den här artikeln planerar jag att berätta hur vi i vår praktik använder Cumulative Flow Chart i Scrum under arbetet med ramverket SAFe

Jag börjar nog med en länk till en sådan artikel - här, enligt min mening, beskrivs dess syfte i standardform väl, jag rekommenderar att studera den före läsningen av min artikel. Nedan beskriver jag hur vi har anpassat den för Scrum-processen (ursprungligen används den i Kanban) och vilka problem den hjälper oss att lösa när vi arbetar i sprintar.

Tidigare, i artikeln om Burn Down Charts har jag redan sagt att där ser vi uppkomsten av nytt arbete och nedbränningen av gammalt. Problemet med Burn Down Chart är att, till skillnad från Cumulative Flow Chart, ser vi inte rörelsen av användarberättelser genom statusarna. När vi börjar observera rörelser genom statusarna i Cumulative Flow Chart börjar vi se dagliga förändringar (Burn Down Chart kan vara oförändrat i flera dagar och i vissa sammanhang kan det vara helt normalt) och kan upptäcka mer subtila problem.

Så här kan det se ut i dynamik (på bilden en diagram byggd på verklig data).

I det här exemplet ser vi följande

• Under sprintens första 7 dagar finns en mycket liten volym arbete i testning och den förändras inte
• Från DOR (här ett utkast) går användarberättelserna till arbete ganska jämnt - det är bra.
• Precis som på Burn Down ser vi att enligt trenden kommer användarberättelserna inte att vara klara till sprintens slut

Dessa 3 observationer leder tillsammans till följande slutsats. Här borde Scrum Mastern uppenbarligen redan i ett tidigt skede (någonstans under sprintens andra–tredje dag) ha uppmärksammat lagret "Testning", som är alltför litet och inte förändras tillräckligt länge (ta reda på orsaken). Man kan anta att volymen arbete som är klar för testning inte kan testas av några omständigheter, men då betyder det att testarna står stilla, och alltså bör man åtminstone lyssna noggrannare på dem på närmaste standup.

Om vi talar om tillämpningspraxis, så publicerar jag till exempel dagligen i teamets chatt alla mätvärden före standupen med omnämnande av hela teamet.

I allmänhet bör man inte glömma att mätvärden ändå måste tolkas korrekt. Att kunna se verkliga systemproblem om de finns och inte uppfatta som problem det som i er kontext till och med kan vara ett positivt tecken