Scrum Guide | 31. Hur man skapar och tolkar ett Burndown-diagram?

En Burndown-diagram är relativt enkel att skapa. Det finns många verktyg tillgängliga för att generera den från det arbete som loggats av medlemmar i Utvecklingsteamet. Trots sin enkelhet kan dess tolkning ge värdefull information för hela Scrum-teamet. Läs den här artikeln för att ta reda på hur man skapar och tolkar en Burndown-diagram.

Hur skapar och tolkar man en Burndown-diagram? – innehållsförteckning:

1. Hur skapar man en Burndown-diagram?
2. Vem är ansvarig för Burndown-diagrammet?
3. Hur tolkar man en Burndown-diagram?
4. Reell och ideal Burndown-diagram
5. Val av mätenhet
6. Sammanfattning

Hur skapar man en Burndown-diagram?

Utvecklingsteamet bör övervaka sitt dagliga arbete. Detta är grunden inte bara för att utvärdera dess effektivitet utan också för att förbättra den. Och ett av de enklaste och beprövade verktygen för detta ändamål är Burndown-diagrammet.

Du kan skapa det manuellt genom att rita ett koordinatsystem på ett papper. På Y-axeln behöver du plotta mängden arbete uttryckt i en vald enhet, till exempel story points. På X-axeln ritar du en skala som indikerar de efterföljande dagarna av Sprinten. Rita en linje för den ideala sprinten och markera sedan antalet realistiskt genomförda uppgifter för varje dag. Även om denna lösning är charmig och engagerar teamet, är den inte särskilt praktisk. Den är inte heller nödvändigtvis lämplig för distansteam.

Därför är digitala medel för att skapa en Burndown-diagram mycket vanligare. Många verktyg för att logga arbete på uppgifter som fördelas bland teammedlemmar kommer med ett alternativ för att automatiskt skapa en Burndown-diagram. Då behöver en utvecklare bara markera början och slutet av arbetet på en viss produktfunktion, och deras bidrag återspeglas i Burndown-diagrammet.

Med rätt verktyg är det också möjligt att fritt skala diagrammet. Detta ger en insikt i förbränningen inte bara på nivån av en given Sprint utan också på skalan av ett kvartal eller hela projektet.

En viktig faktor att överväga när man väljer ett verktyg för att skapa en Burndown-diagram är dess tillgänglighet för alla Scrum-teammedlemmar. Synligheten av Burndown-diagrammet för hela Utvecklingsteamet är en nyckelmotiverande faktor. Lika viktigt är en daglig titt på linjen som visar det arbete som återstår att göra. Att prata om burn-in under Daily Scrum får utvecklarna att tänka på sätten de arbetar på och det aktuella tillståndet av produkten.

Vem är ansvarig för Burndown-diagrammet?

Frågan om ägande av Burndown-diagrammet är något kontroversiell. Å ena sidan bör det tillhöra Scrum Master, eftersom det är ett verktyg för att säkerställa att teamet arbetar effektivt och enligt plan. Å andra sidan bör det förbli i händerna på Produktägaren, eftersom det återspeglar framstegen mot ett Produktmål som kommuniceras till kunden. Dessutom är en tredje part som kan hävda sitt ägande Utvecklingsteamet, eftersom diagrammet fungerar som deras interna verktyg.

Burndown-diagrammet är en viktig mätning för att utvärdera effektiviteten hos Utvecklingsteamet och blir antaget av alla Scrum-teammedlemmar. Det är därför transparens och tillgänglighet är avgörande. Men dess syfte är att tjäna teamet. Det ska stärka dess självorganisation, förbättra motivationen och ge en verklig bild av statusen för arbetet med de tilldelade uppgifterna. Därför kan i teorin varje medlem av Utvecklingsteamet uppdatera Burndown-diagrammet.

I praktiken faller dock uppgiften att uppdatera Burndown-diagrammet vanligtvis på Scrum Master. Detta händer särskilt i början av hans arbete med ett nytt Utvecklingsteam när Teamets hastighet fortfarande är variabel och svår att uppskatta. Ändå rekommenderas det att delegera denna uppgift till en av utvecklarna. Trots allt är diagrammet avsett att vara en ärlig och intern mätning av framstegen i arbetet som bedöms av utvecklarna själva.

Hur tolkar man en Burndown-diagram?

Vi beskrev utseendet på Burndown-diagrammet i detalj i en tidigare artikel. Här påminner vi bara om att X-axeln visar tiden kvar för att slutföra arbetet. Å andra sidan visar Y-axeln mängden arbete som återstår att göra.

Reell och ideal Burndown-diagram

För att tolka en Burndown-diagram är den avgörande faktorn inte bara den regelbundna plottningen av den verkliga “förbränningen”, dvs. genomförandet av uppgifter av Utvecklingsteamet. Lika viktigt för bilden är dess jämförelse med den ideala förbränningslinjens nedgång (riktlinje).

Genom att jämföra den ideala brännlijnen med den verkliga minskningen av arbete som markeras på Burndown-diagrammet, kan två mycket viktiga parametrar bedömas. För det första, för att se om arbetet fortsätter i nuvarande takt, kommer Utvecklingsteamet att möta Sprintmålet eller Produktmålet i tid. För det andra, för att få en uppfattning om när arbetet kommer att vara klart medan den nuvarande takten bibehålls. Med andra ord, Burndown-diagrammet visar den faktiska takten för uppgifterna, och den ideala linjen visar i vilken takt teamet bör arbeta för att slutföra uppgifterna.

Burndown-diagrammet möjliggör också att bestämma ett värde som kallas Utvecklingsteamets hastighet på lång sikt. Vi kommer att ägna en separat artikel åt det. Här nämner vi bara att det är ett värde som bestäms av mängden arbete som utförts under en Sprint.

Tack vare att Burndown-diagrammet illustrerar jämförelsen av en ideal brännlijn med en verklig minskning av antalet uppgifter, gör det möjligt att uppskatta arbetstakten. Och därmed förutse risken för projektförseningar.

Val av mätenhet

Teamets hastighet mäts vanligtvis i enheter som kallas story points. Det definierar antalet användarberättelser som har realiserats. Dessa kan kräva mycket olika mängder arbete.

Det är därför många Scrum-team använder en tidsbaserad mätning. Beroende på skalan är dessa dagar eller man-timmar. Varje utvecklare uppskattar och loggar sedan den tid som spenderats på sina uppgifter.

Ett annat alternativ är att anta uppgifter som enhet. Dessa är något större enheter, som i sin tur tilldelas ett värde uttryckt i story points, eller i dagar eller man-timmar. Det är en enhet som gör det möjligt för kunden att presentera framstegen i arbetet med produkten på ett tydligare sätt.

Oavsett mätenhet är det värt att komma ihåg principen för att beräkna hastigheten hos Utvecklingsteamet. Under en given dag eller Sprint räknas endast uppgifter som faktiskt har slutförts. Det betyder att påbörjade uppgifter kommer att räknas mot nästa dag eller Sprint även om endast sluttestning saknas.

Sammanfattning

Med de övervakningsverktyg som finns tillgängliga för teamet, blir det en enkel uppgift att skapa en Burndown-diagram. Den viktigaste frågan är att säkerställa dess koherens, tydlighet och tillgänglighet för alla Scrum-teammedlemmar.

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