Praxis för användning av Burn Down Charts i SAFe- och Scrum-sammanhang

I den här artikeln planerar jag att berätta hur vi i vår praktik använder Burn Down Chart i arbetet enligt SAFe-metodiken

Jag börjar nog med det mest intressanta. Nämligen med att användningen av den här diagrammet i SAFe inte bör ha någon specifik karaktär jämfört med användningen av den här diagrammet i SCRUM. Eller borde den?

SAFe hos oss skiljer sig genom att ha en sådan roll som RTE, till skillnad från SCRUM, där den inte finns. Burn Down Chart är ett verktyg för att spåra arbetsmängden i en sprint och det behövs framför allt för SCRUM-teamet, inte för någon utomstående, eller hur?

Således går jag ändå över till hur vi använder Burn Down Chart, trots allt, och fortfarande inom SAFe-ramverket.

Jag är i rollen som Scrum Master och försöker lyfta fram den här diagrammet dagligen för hela Dev Team. Verktyget jag använder är teamchatten, omnämnande av hela teamet via "@", en skärmbild av diagrammets aktuella tillstånd. Omnämnande av hela teamet är ett ganska känsligt verktyg och det är viktigt att använda det så sällan som möjligt (vi Scrum Masters måste ju hjälpa teamet att arbeta i komfort och med minsta möjliga distraktion, eller hur?)

I slutändan ser teamet dagligen sprintens aktuella tillstånd och kan följa följande händelser

• Uppkomst av oplanerat arbete
• Långvarig kvarsittning av uppgifter i ofullbordat status
• Överdriven inlagring av risker
• Förståelse för om arbetet går i rätt takt

Härnäst ska jag försöka utveckla var och en av dessa händelser och ge exempel från min praktik.

Uppkomst av oplanerat arbete

I den här diagrammet syns det mycket väl hur nytt arbete uppstår (under den andra tisdagen i en tvåveckorssprint).

Fall från praktiken: "Utvecklaren, som medlem i scrum-teamet som delar agile-principerna, samarbetar utmärkt med Produktägaren direkt. Produktägaren säger till honom att det här måste vi få till snabbt, du förstår själv, här går det snabbt och riskerna är minimala.

Utvecklaren är duktig, han vet allt om agile och om vikten av att leverera affärsvärde, går och lägger upp en story från backloggen på tavlan, den är skattad av teamet till 6 sp.

Resten av teamet (förutom utvecklaren och Produktägaren) märker detta vid morgonuppdateringen av diagrammet. På standupen fattar teamet beslut om hur situationen ska hanteras. Troligtvis kastas storyn ut ur sprinten, teamet gör klart för Produktägaren och Utvecklaren att man inte kan göra så, produktägaren kan vid behov lägga in storyn i nästa sprint.

Naturligtvis borde teamet idealt märka uppkomsten av nytt arbete på standupen även utan diagrammet. Men diagrammet är en bra indikator som minimerar riskerna att inte märka en så viktig förändring för hela teamet.

Här är det viktigt att förstå att scenariot kunde ha utvecklats olika beroende på teamets nivå. I grymma team skulle Produktägaren knappast ha gjort så, och om han hade gjort det skulle han ha argumenterat inte med att "det här går snabbt att få till", utan med att "jag bedömer sannolikheten till 55% att om vi får till det här nu så kan det öka vår vinst med 20% nästa månad" eller någon annan mätbar metrik.

Långvarig kvarsittning av uppgifter i ofullbordat status

Här ser vi att arbetet under mycket lång tid inte slutförs ens delvis. Detta kan signalera om olika problem, jag listar några av dem

• Dålig uppdelning av uppgifter

  Mycket ofta säger nybörjarteam att uppdelning är omöjlig. Hos dem brinner allt upp den sista dagen, arbetet parallelliseras inte osv. Naturligtvis måste Scrum Mastern arbeta med detta och förklara värdet av uppdelning för teamet.

• Inte optimalt formulerad DOD

  DOD (Definition of Done) - beskrivning av kriterierna för när en User Story är klar i sprinten. Ibland finns de inte alls eller så är de beskrivna mycket abstrakt. Detta kan mycket väl vara ett problem, som naturligtvis Scrum Mastern bör hjälpa till att lösa

Överdriven inläggning av risker

I detta fall ser vi en situation där teamet har lagt in för stora risker.

Möjligen har någon story överskattats. Möjligen är detta ett mer systematiskt problem och det är nödvändigt att öka arbetsvolymen vid sprintplaneringen. I vilket fall som helst är denna situation inte korrekt. Trots allt planerade verksamheten att det skulle genomföras just sprintens uppgifter och just i slutet av sprinten. Beroende på hur beroendena planerades, kommer man här troligen att behöva hålla möten för att justera förväntningarna.

I min praktik hände detta när man hittade en snabbare lösning än den som diskuterades vid uppskattningen. Vi diskuterade i hela teamet vilken story vi skulle kunna stänga före sprintens slut och på retrospektivet kom vi överens om att vi skulle försöka titta på koden vid grooming. Det visade sig att det räckte att helt enkelt titta i koden för att förstå att lösningen var mycket enklare.

Förståelse - går arbetet i rätt takt

Här skulle jag vilja uppmärksamma grafiskt misslyckade sätt att visa Burn Down Chart

I den övre delen av bilden ges ett exempel på en inte särskilt lyckad grafisk implementation av två skäl, som jag kommer att redogöra för nedan.

• Det är inte märkbart att nya SP hamnar i sprinten

  Här, i det övre diagrammet, är det praktiskt taget inte märkbart att oplanerat arbete har lagts till. I det nedre är det tydligare.

• Den relativa återstående arbetsmängden visas felaktigt

  Enligt det övre diagrammet återstår 3 dagar att arbeta. I själva verket är de 2, på ledigdagen planerar kanske någon att vila.

Naturligtvis kan sådana småsaker verka obetydliga för någon. Men man måste förstå att varje medlem i teamet bara kastar en blick på detta diagram och det måste förmedla maximalt med användbar information.