Scrum Guide | 32. Fördelar och nackdelar med Burndown-diagrammet

Burndown-diagrammet har många fördelar. Det är ett av de viktigaste mätverktygen inom Scrum av flera anledningar. Det är enkelt att skapa, skala och läsa. Men det har också nackdelar som gör att det inte är ett universellt verktyg. I dagens artikel tar vi upp ämnet nackdelar och fördelar med Burndown-diagrammet.

Fördelar och nackdelar med Burndown-diagrammet – innehållsförteckning:

1. Introduktion
2. Fördelar med Burndown-diagrammet
3. Nackdelar med Burndown-diagrammet
4. Sammanfattning

Introduktion

Vi har skrivit om vad det är, hur man skapar och tolkar ett Burndown-diagram i tidigare artiklar. Idag kommer vi att fokusera på fördelarna och nackdelarna med Burndown-diagrammet. Men de flesta av dem är inte dolda i det enkla diagrammet i sig. Snarare är de relaterade till sätten att använda Burndown-diagrammet för att motivera utvecklingsteamet, eftersom de beskriver resultaten av deras arbete och stärker självorganisering.

Fördelar med Burndown-diagrammet

Burndown-diagrammet gör att du kan visualisera framstegen i ditt projekt. Dess läsbarhet och enkelhet gör det så populärt. Därför är det en bra idé att Burndown-diagrammet inte bara är en ständigt uppdaterad mätning som döljs i ett digitalt projektledningsverktyg. Om det är möjligt, är det värt att göra det till en referenspunkt för utvecklingsteamet som är synlig på den fysiska arbetsplatsen. Oavsett om det är i form av en skärmvisualisering eller en handritad skiss.

Det motiverar utvecklingsteamet

Transparensen i Burndown-diagrammet kan göra det till ett verktyg för att motivera utvecklingsteamet att arbeta effektivt. Att nå “noll”-punkten i varje Sprint kan bli ett ambitiöst mål för teamet, för vilket belöningar ges – enligt principerna för affärsgamification.

Synligheten av ett aktuellt och intressant underhållet Burndown-diagram kan också öka andan av samarbete och självorganisering. Trots allt är mätningen ett mått på teamwork. Det visar inte exakt vem som gjorde – eller inte gjorde – de planerade uppgifterna, bara de uppnådda resultaten.

Det mäter det faktiska utförda arbetet

Utvecklarna bestämmer hur många uppgifter de kommer att utföra i en given Sprint. Ju mer erfarna teamet är, desto mer exakt bör de kunna förutsäga sina handlingar. Och Burndown-diagrammet återspeglar den verkliga framstegen i Sprinten.

Därför är fördelen med Burndown-diagrammet inte så mycket att mäta den objektiva mängden utfört arbete, utan förhållandet mellan planerade och genomförda uppgifter. Således lär sig utvecklarna gradvis hur man planerar dem och kan uppskatta sina förmågor mer och mer exakt och eliminera repetitiva fel.

Det kopplar ihop med andra verktyg

En av de betydande fördelarna med Burndown-diagrammet rör dess mångsidighet i kombination med andra verktyg. Följande verktyg kan tillämpas på:

• analysera arbetet i utvecklingsteamet
• visualisera framstegen i arbetet med produkten
• uppskatta projektbudgeten

Till exempel, i det senare fallet, gör användningen av Projektets Skala Burndown-diagram det möjligt att jämföra den planerade och faktiska budgeten för hela projektet.

Nackdelar med Burndown-diagrammet

Trots alla fördelar med Burndown-diagrammet som beskrivits ovan, kan det bli en källa till förvirring för utvecklingsteamet. Men vad vi ofta kallar “brister” i Burndown-diagrammet beror inte på verktygets egna brister. De problem som beskrivs nedan rör sättet att implementera Burndown-diagrammet snarare än dess design. Nedan följer bristerna som kan störa avbildningen av utvecklingsteamets framsteg på detta sätt.

“Den mänskliga faktorn”

Diagram kan inte vara ett absolut mått på ett teams framsteg. De är bara verktyg som kan tillämpas på olika, mer eller mindre skickliga sätt. Vi kan betrakta det som en nackdel (eller fördel) inte bara av Burndown-diagrammet utan också av andra mått på teamets prestation.

För att skapa ett Burndown-diagram, behöver du andra människor för att mata in data. Med andra ord, utvecklarna skriver ner tiden för uppgiftsavslutning i diagrammet. De kan ha förlängt eller förkortat den lite – antingen genom ouppmärksamhet eller för att göra saker bättre för teamet. Utvecklarna glömmer också ibland att logga sin tid. Eller lämnar timern på. Detta gör att arbetstiden sträcker sig över flera timmar. Och efter att ha upptäckt felet är det svårt att återskapa dess verkliga förlopp.

Ändringar i Sprint Backlog

Sprint Backlog bör inte ändras efter att en Sprint har startat. Men i praktiken förekommer sådana ändringar ganska ofta. De beror på förändrade krav från intressenter. Eller oförutsedda problem som utvecklarna stöter på.

Detta gör att Burndown-diagrammet skalas. Detta beror på att den tid som krävs för att slutföra uppgifterna förblir densamma. Men skalan av återstående uppgifter ökar. Detta kan ge ett missvisande intryck av att utvecklingsteamet har planerat arbetet felaktigt i en given Sprint. Eller att det arbetar för långsamt.

Ändringar i Sprint Backlog kan också bero på uppgifter som var planerade för att slutföras för snabbt. I en sådan situation beslutar utvecklingsteamet vanligtvis att öka antalet uppgifter. Detta kan i sin tur leda till att de inte slutförs i tid. Dessutom kan konflikter uppstå från överlappningen av återstående uppgifter från den föregående Sprinten med nya uppgifter som ska slutföras av intressenter och produktägare.

Ändringar i Produkt Backlog

Stora förändringar i Produkt Backlog kan störa formen av Burndown-diagrammet. Och därmed starkt förvränga bilden av arbetsframsteg och teamets effektivitet. Detta händer när nya användarberättelser dyker upp. Och de som är nära implementeringsfasen bryts ofta ner i mindre delar. Det händer också att klienten avstår från vissa produktfunktioner.

Därför, när man tolkar Burndown-diagrammet, måste man styras av kunskap och erfarenhet i att utvärdera teamets prestation. Och också ta hänsyn till variabiliteten i Backloggen. Om diagrammet inte är den enda mätningen som används för att utvärdera prestation, kommer de andra diagrammen att ge en mer komplett bild av arbetsframstegen.

Sammanfattning

Burndown-diagrammet kan avsevärt bidra till motivation av utvecklingsteamet. Detta beror på att det ger ett mått på det verkliga arbetet som utförts enligt planen. Dessutom kan dess kombination med andra mätverktyg vara en källa till värdefull kunskap om teamets arbete och produktplanering.

Genom att noggrant tillämpa Scrum-principerna kan du undvika potentiella problem med Burndown-diagrammet. Det viktigaste är att anpassa verktygen för att hålla diagrammet i enlighet med det faktiska arbetet i Scrum-teamet, samt att minimera förändringar i Sprint- och Produkt Backlog, vilket vi skriver mer om i denna artikel.

Om du gillar vårt innehåll, gå med i vår aktiva community av busy bees på Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.