Burndown-diagrammet har mange fordele. Det er et af de vigtigste måleværktøjer i Scrum af flere grunde. Det er nemt at oprette, skalere og læse. Men det har også ulemper, der gør det til et ikke-universelt værktøj. I dagens artikel dækker vi emnet om ulemper og fordele ved Burndown-diagrammet.
Vi har skrevet om hvad det er, hvordan man opretter og fortolker et Burndown-diagram i tidligere artikler. I dag vil vi fokusere på fordelene og ulemperne ved Burndown-diagrammet. Men de fleste af dem er ikke skjult i det enkle diagram i sig selv. Snarere er de relateret til måderne at bruge Burndown-diagrammet til at motivere udviklingsteamet, da de beskriver resultaterne af deres arbejde og styrker selvorganisering.
Burndown-diagrammet giver dig mulighed for at visualisere fremskridtene i dit projekt. Dets læsbarhed og enkelhed gør det så populært. Derfor er det en god idé, at Burndown-diagrammet ikke kun er en konstant opdateret måling gemt i et digitalt projektstyringsværktøj. Hvis det overhovedet er muligt, er det værd at gøre det til et referencepunkt for udviklingsteamet synligt i det fysiske arbejdsområde. Uanset om det er i form af en skærmvisualisering eller en håndtegnet skitse.
Transparensen i Burndown-diagrammet kan gøre det til et værktøj til at motivere udviklingsteamet til at arbejde effektivt. At nå “nul”-punktet i hver Sprint kan blive et ambitiøst mål for teamet, for hvilket der gives belønninger – i henhold til principperne for forretningsgamification.
Synligheden af et opdateret og interessant vedligeholdt Burndown-diagram kan også styrke ånden af samarbejde og selvorganisering. Trods alt er målingen et mål for teamwork. Det viser ikke præcist, hvem der har – eller ikke har – gennemført de planlagte opgaver, kun de opnåede resultater.
Udviklere beslutter, hvor mange opgaver de vil udføre i en given Sprint. Jo mere erfarent teamet er, jo mere præcist bør de forudsige deres handlinger. Og Burndown-diagrammet afspejler de reelle fremskridt i Sprinten.
Derfor er fordelen ved Burndown-diagrammet ikke så meget at måle den objektive mængde af udført arbejde, men forholdet mellem planlagte og gennemførte opgaver. Dermed lærer udviklerne gradvist, hvordan de skal planlægge dem og kan estimere deres kapaciteter mere og mere præcist og eliminere gentagne fejl.
En af de væsentlige fordele ved Burndown-diagrammet vedrører dets alsidighed i kombination med andre værktøjer. Følgende værktøjer kan anvendes til:
For eksempel i sidstnævnte tilfælde tillader brugen af Project Scale Burndown-diagrammet en sammenligning af det planlagte og faktiske budget for hele projektet.
På trods af alle fordelene ved Burndown-diagrammet, der er skitseret ovenfor, kan det blive en kilde til forvirring for udviklingsteamet. Men det, vi ofte kalder “fejl” ved Burndown-diagrammet, skyldes ikke værktøjets egne mangler. De problemer, der er skitseret nedenfor, vedrører måden at implementere Burndown-diagrammet på snarere end dets design. Nedenfor er de fejl, der kan forstyrre skildringen af fremskridtene i udviklingsteamet på denne måde.
Diagrammer kan ikke være et absolut mål for et teams fremskridt. De er blot værktøjer, der anvendes på forskellige, mere eller mindre dygtige måder. Vi kan betragte det som en ulempe (eller fordel) ikke kun ved Burndown-diagrammet, men også ved andre målinger af teamets præstation.
For at oprette et Burndown-diagram har du brug for andre mennesker til at indtaste data. Med andre ord, udviklerne noterer tid til opgaveafslutning på diagrammet. De kan have forlænget eller forkortet det lidt – enten gennem uopmærksomhed eller for at gøre tingene bedre for teamet. Udviklere glemmer også nogle gange at logge deres tid. Eller lader timeren køre. Dette får arbejdstiden til at strække sig over flere timer. Og efter at have opdaget fejlen er det svært at rekonstruere dens reelle forløb.
Sprint Backlog bør ikke ændres efter starten af en Sprint. Men i praksis sker sådanne ændringer ret ofte. De skyldes ændrede krav fra interessenter. Eller uforudsete problemer, som udviklerne støder på.
Dette får Burndown-diagrammet til at blive skaleret. Dette skyldes, at den tid, der bruges på at fuldføre opgaverne, forbliver den samme. Men skalaen af de resterende opgaver stiger. Dette kan give et misvisende indtryk af, at udviklingsteamet har planlagt arbejdet forkert i en given Sprint. Eller at det arbejder for langsomt.
Ændringer i Sprint Backlog kan også skyldes opgaver, der var planlagt til at blive afsluttet for hurtigt. I en sådan situation beslutter udviklingsteamet normalt at øge antallet af opgaver. Dette kan igen resultere i, at de ikke bliver afsluttet til tiden. Også kan der opstå konflikter fra overlapningen af resterende opgaver fra den forrige Sprint med nye opgaver, der er planlagt til at blive afsluttet af interessenter og produktejere.
Store ændringer i Product Backlog kan forstyrre formen af Burndown-diagrammet. Og dermed stærkt forvrænge billedet af arbejdsfremskridt og teamets effektivitet. Dette sker, når nye brugerhistorier dukker op. Og dem, der er tæt på implementeringsfasen, bliver ofte opdelt i mindre dele. Det sker også, at klienten trækker sig fra nogle produktfunktionaliteter.
Derfor, når man fortolker Burndown-diagrammet, skal man ledes af viden og erfaring i vurderingen af teamets præstation. Og også tage højde for variabiliteten i Backlog. Hvis diagrammet ikke er den eneste måling, der bruges til at evaluere præstationen, vil de andre diagrammer give dig et mere komplet billede af arbejdsfremskridtene.
Burndown-diagrammet kan i høj grad bidrage til motivation af udviklingsteamet. Dette skyldes, at det giver et mål for det reelle arbejde udført i planen. Desuden kan dets kombination med andre måleværktøjer være en kilde til værdifuld viden om teamets arbejde og produktplanlægning.
Ved omhyggeligt at anvende Scrum-principperne kan du undgå potentielle problemer med Burndown-diagrammet. Det vigtigste er at tilpasse værktøjerne til at holde diagrammet i overensstemmelse med det faktiske Scrum-teams arbejde, samt at minimere ændringer i Sprint- og Product Backlog, som vi skriver mere om i denne artikel.
Hvis du kan lide vores indhold, så bliv en del af vores travle bier-fællesskab på Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.
Som projektleder er Caroline en ekspert i at finde nye metoder til at designe de bedste arbejdsgange og optimere processer. Hendes organisatoriske færdigheder og evne til at arbejde under tidspres gør hende til den bedste person til at gøre komplicerede projekter til virkelighed.
Får du nogensinde følelsen af, at dagen er for kort til at gøre alt det,…
Hvad er software? Hvad er typerne og metoderne til distribution? Når vi holder os til…
At præsentere og kommunikere forskningsresultater er sandsynligvis en af de mest afgørende (og krævende) evner…
Ved du, hvordan man opretter en e-bog? Kender du alle de væsentlige aspekter af en…
Bæredygtig markedsføring er ikke længere bare en af de markedsføringsstrategier, du kan anvende i din…
For nylig er to fænomener opstået på arbejdsmarkedet, der relaterer sig til holdningerne hos nutidens…