Scrum Guide | 31. Hvordan man opretter og fortolker et Burndown-diagram?

Et Burndown-diagram er relativt nemt at oprette. Der findes mange værktøjer til at generere det ud fra det arbejde, der er logget af medlemmerne af udviklingsteamet. På trods af sin enkelhed kan dets fortolkning give værdifuld information til hele Scrum-teamet. Læs denne artikel for at finde ud af, hvordan man opretter og fortolker et Burndown-diagram.

Hvordan opretter og fortolker man et Burndown-diagram? – indholdsfortegnelse:

1. Hvordan opretter man et Burndown-diagram?
2. Hvem er ansvarlig for Burndown-diagrammet?
3. Hvordan fortolker man et Burndown-diagram?
4. Reelt og ideelt Burndown-diagram
5. Valg af måleenhed
6. Sammendrag

Hvordan opretter man et Burndown-diagram?

Udviklingsteamet bør overvåge sit daglige arbejde. Dette er grundlaget ikke kun for at evaluere dets effektivitet, men også for at forbedre det. Og et af de simpleste og mest pålidelige værktøjer til dette formål er Burndown-diagrammet.

Du kan oprette det manuelt ved at tegne et koordinatsystem på et stykke papir. På Y-aksen skal du plotte mængden af arbejde udtrykt i en valgt enhed, for eksempel story points. På X-aksen tegner du en skala, der angiver de på hinanden følgende dage i Sprinten. Tegn en linje for den ideelle sprint og marker derefter antallet af realistisk gennemførte opgaver for hver dag. Selvom denne løsning er charmerende og engagerer teamet, er den ikke særlig praktisk. Den er heller ikke nødvendigvis egnet til fjernteams.

Derfor er digitale midler til at oprette et Burndown-diagram meget mere almindelige. Mange værktøjer til at logge arbejdet på opgaver, der er fordelt blandt teammedlemmerne, kommer med en mulighed for automatisk at oprette et Burndown-diagram. Så alt, hvad en udvikler skal gøre, er at markere starten og slutningen af arbejdet på en bestemt produktfunktion, og deres bidrag afspejles i Burndown-diagrammet.

Med de rigtige værktøjer er det også muligt at skale diagrammet frit. Dette giver indsigt i forbrændingen ikke kun på niveauet af en given Sprint, men også på skalaen af et kvartal eller hele projektet.

En vigtig faktor at overveje, når man vælger et værktøj til at oprette et Burndown-diagram, er dets tilgængelighed for alle Scrum-teammedlemmer. Synligheden af Burndown-diagrammet for hele udviklingsteamet er en nøglemotivationsfaktor. Lige så vigtigt er det at se dagligt på linjen, der viser det arbejde, der er tilbage at udføre. At tale om burn-in under Daily Scrum får udviklerne til at tænke over de måder, de arbejder på, og den nuværende tilstand af produktet.

Hvem er ansvarlig for Burndown-diagrammet?

Spørgsmålet om ejerskab af Burndown-diagrammet er noget kontroversielt. På den ene side bør det tilhøre Scrum Masteren, fordi det er et værktøj til at sikre, at teamet arbejder effektivt og i henhold til planen. På den anden side bør det forblive i hænderne på Product Owneren, fordi det afspejler fremskridtene mod et produktmål, der kommunikeres til kunden. Hvad mere er, en tredje part, der kan kræve ejerskab, er udviklingsteamet, da diagrammet fungerer som deres interne værktøj.

Burndown-diagrammet er en essentiel måling til at evaluere effektiviteten af udviklingsteamet og bliver vedtaget af alle Scrum-teammedlemmer. Derfor er gennemsigtighed og tilgængelighed afgørende. Men dets formål er at tjene teamet. Det skal styrke dets selvorganisering, forbedre motivationen og give et reelt billede af status for arbejdet på de opgaver, der er tildelt det. Derfor kan i teorien hvert medlem af udviklingsteamet opdatere Burndown-diagrammet.

I praksis falder opgaven med at opdatere Burndown-diagrammet normalt til Scrum Masteren. Dette sker især i starten af hans arbejde med et nyt udviklingsteam, når teamets hastighed stadig er variabel og svær at estimere. Ikke desto mindre anbefales det at delegere denne opgave til en af udviklerne. Trods alt er diagrammet ment som en ærlig og intern måling af fremskridtene i arbejdet, som vurderes af udviklerne selv.

Hvordan fortolker man et Burndown-diagram?

Vi har beskrevet udseendet af Burndown-diagrammet i detaljer i en tidligere artikel. Her vil vi kun minde dig om, at X-aksen viser den tid, der er tilbage til at fuldføre arbejdet. På den anden side viser Y-aksen mængden af arbejde, der er tilbage at udføre.

Reelt og ideelt Burndown-diagram

For at fortolke et Burndown-diagram er den nøglefaktor ikke kun den regelmæssige plotning af den reelle “forbrænding”, dvs. udførelsen af opgaverne af udviklingsteamet. Lige så vigtigt for billedet er sammenligningen med den ideelle forbrændingslinjes fald (retningslinje).

Ved sammenligning af den ideelle brændelinje med den reelle reduktion i arbejdet markeret på Burndown-diagrammet kan to meget vigtige parametre vurderes. For det første, for at se om arbejdet fortsætter i det nuværende tempo, vil udviklingsteamet nå Sprint-målet eller produktmålet til tiden. For det andet, for at få en idé om, hvornår arbejdet vil være færdigt, mens det nuværende tempo opretholdes. Med andre ord, Burndown-diagrammet viser den faktiske hastighed af opgaverne, og den ideelle linje viser, med hvilken hastighed teamet bør arbejde for at fuldføre opgaverne.

Burndown-diagrammet giver også mulighed for at bestemme en værdi kaldet udviklingsteamets hastighed på lang sigt. Vi vil dedikere en separat artikel til det. Her vil vi blot nævne, at det er en værdi, der bestemmes af mængden af arbejde udført i løbet af en Sprint.

Takket være det faktum, at Burndown-diagrammet illustrerer sammenligningen af en ideel brændelinje med en reel reduktion i antallet af opgaver, giver det mulighed for at vurdere arbejdstempoet. Og dermed forudse risikoen for projektforsinkelser.

Valg af måleenhed

Teamets hastighed måles normalt i enheder kaldet story points. Det definerer antallet af brugerhistorier, der er blevet realiseret. Disse kan kræve meget forskellige mængder arbejde.

Derfor bruger mange Scrum-teams en tidsbaseret måling. Afhængigt af skalaen er disse dage eller mandetimer. Hver udvikler estimerer og logger derefter den tid, der er brugt på deres opgaver.

En anden mulighed er at vedtage opgaver som enhed. Disse er lidt større enheder, som igen tildeles en værdi udtrykt i story points eller i dage eller mandetimer. Det er en enhed, der gør det muligt for kunden at præsentere fremskridtene i arbejdet på produktet på en klarere måde.

Uanset måleenheden er det værd at huske princippet om at beregne hastigheden af udviklingsteamet. I en given dag eller Sprint tæller kun opgaver, der faktisk er blevet afsluttet. Det betyder, at opgaver, der er påbegyndt, vil blive talt med til den næste dag eller Sprint, selvom der kun mangler sluttestning.

Sammendrag

Med de tilgængelige værktøjer til teamovervågning bliver det en nem opgave at oprette et Burndown-diagram. Det vigtigste spørgsmål er at sikre dets sammenhæng, klarhed og tilgængelighed for alle Scrum-teammedlemmer.

Hvis du kan lide vores indhold, så bliv en del af vores travle bier-fællesskab på Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.