Olika typer av Burn Graphs
Sprint Burndown är en artefakt i Scrum[1] och den har en stor möjlighet att sprida information till hela teamet och övriga intressenter om hur mycket arbete som återstår i det Sprint som pågår. Både av egen erfarenhet och vad jag har hört berättas så ser de ut på olika sätt i olika implementationer av Scrum. Därför tänkte jag reda ut hur utvecklingen kan påverkas beroende på hur man väljer att rita sin Sprint Burndown.
Burndown baserat på estimering av uppgifter
I den officiella versionen av Scrum[1] ska varje uppgift som finns på en Sprint Backlog ha ett estimat av hur mycket som återstår innan uppgiften är helt färdig. Över tiden uppdateras estimaten för att ständigt spegla den återstående mängden arbete. Om man summerar alla uppgifters estimat får man därför totala mängden arbete som återstår.
På det här sättet får man en kurva som både rör sig upp och ned beroende på hur uppfattningen om uppgifterna förändras under tidens gång. Det låter intuitivt bra, men den effekt som ofta uppstår är att det blir ett för stort fokus på att ständigt minska estimatens storlek. Det sker ofta på bekostnad av att se till att slutföra en uppgift helt istället. Det är trots allt enklare att ändra ett estimat på en lapp än att faktiskt se till att uppgiften blir helt klar. Drar man det till sin spets får man en Burndown Graph som går nästan hela vägen ner till noll utan att någon enda uppgift blivit helt färdig.
För att se till att ändra fokus till att slutföra uppgifter är det naturliga steget att man enbart får dra ner grafen när en uppgift är helt färdig, dvs inga omestimeringar görs. På så sätt får teamet bara belöning när en uppgift faktiskt är klar och går att leverera.
Burndown baserat på antalet uppgifter
Nästa fråga är varför teamet måste ha estimat på alla uppgifter? Det kan ofta kännas naturligt att istället räkna antalet uppgifter som återstår för att använda till sin Sprint Burndown. Den vanligaste anledningen till varför team trots allt vill använda estimat för uppgifter är att uppgifterna varierar för mycket i storlek. Några uppgifter kanske bara tar några minuter medan andra tar flera dagar att få färdiga. Det här är ett tecken på att teamet har problem med att bryta ner sina uppgifter i mindre, jämnsmå delar. Det handlar mycket om att utmana sin egen uppfattning om vad som är en verkligt atomär uppgift, men det är ett ämne för ett senare tillfälle.
Om teamet känner sig komfortabla med att räkna fram en Sprint Burndown baserat på antalet uppgifter finns det fortfarande ett problem. Ett team som gör ett någorlunda bra jobb och reflekterar över den lösning de bygger kommer ofta att upptäcka nya uppgifter som måste utföras för att kunna leverera den funktionalitet som de har tagit på sig. Det kan på olika sätt visualiseras i Sprint Burndown, men alla sätt jag har sett resulterar i en bestraffning av teamet. Det blir ett hack uppåt i kurvan och det hacket beror egentligen inte på att det tillkommit nya uppgifter utan faktiskt att teamet har upptäckt uppgifter som alltid funnits. Teamet kommer alltså att bedömas utfrån en graf som säger att de har mer arbete kvar än innan, men i själva verket har de bara upptäckt arbete som ingen tänkt på förut. Teamet borde väl om något snarare belönas för att de aktivt reflekterar över den lösning de bygger och hittar det som saknas?
Burndown baserat på User Stories
Ett sätt att komma undan den onödiga detaljrikedom som uppstår när Sprint Burndown ritas baserat på uppgifter är att införa User Stories[2] eller något liknande som samlar ihop de uppgifter som tillsammans utgör en funktion. Fördelen är att mängden av User Stories ska vara konstant under ett helt Sprint och därmed blir Sprint Burndown tydligare och fokuserar dessutom på att teamet ska göra färdigt hela funktionalitetsstycken för att få belöning. Med den här versionen av Sprint Burndown slipper teamet även undan den bestraffning som tidigare uppstod när nya uppgifter tillkommer, eftersom de blir en naturlig del av att utveckla en User Story färdigt.
Samma argumentation som förts om föränderliga estimat och om hurvida det är estimaten eller antalet uppgifter som ska räknas går att göra för User Stories också. Även här är det bättre om teamet blir effektivare på att bryta ner funktionaliteten till mindre och mer enhetliga delar. Med mindre User Stories får teamet dessutom en tydligare översikt över vad som ska göras för varje funktionalitet.
Ett argument för att inte basera sitt Sprint Burndown på User Stories är att det inte händer så mycket med kurvan under långa perioder. Problemet i det fallet är dock inte att teamet baserar sin Burndown på estimat från User Stories utan snarare att dessa är för stora och övergripande. Den information den plana kurvan ger till teamet är alltså att det har spenderats för lite tid på att bryta ner den funktionalitet som ska implementeras och därför straffas teamet genom för stora och oöverskådliga User Stories.
Burnup
Ett alternativt till Burndown som jag tycker verkar väldigt intressant är Burnup[3][4]. Det tydliggör på ett helt annat sätt när omfånget av vad som ska göras ändras. Jag har inte själv haft möjlighet att använda det "på riktigt" ännu så jag har ännu inte sett vilka situationer Burnup passar bra eller mindre bra i, men jag ser fram emot att få experimentera med det i framtiden.
Sammanfattning
Oavsett hur man väljer att representera sin Sprint Burndown finns det effekter av detta och det generella tips jag vill ge till alla team är att se till att bryta ner sina User Stories och uppgifter till mindre och framför allt mer enhetliga delar. På så sätt blir både översikten över vad som ska göras bättre och ens Sprint Burndown visar tydligare på hur teamet ligger till i arbetet.
--Stefan Östergaard
[1] Scrumguide, Ken Schwaber,
http://www.scrumalliance.org/resource_download/598
[2] Advantages Of User Stories For Requirements, Mike Cohn,
http://www.mountaingoatsoftware.com/articles/27-advantages-of-user-stories-for-requirements
[3] Burn-up and Burn-down Charts, Shane Doan,
http://guidewiredevelopment.wordpress.com/2009/01/29/burn-up-and-burn-down-charts/
[4] Forget Burndown Use Burnup Charts, Lee Richardson,
http://www.nearinfinity.com/blogs/lee_richardson/forget_burndown_use_burnup_charts.html