Hvorfor har Scrum Master brug for statistik og målinger? Først for at tjekke, om hans arbejdsmetoder for forudsigeligheden af resultater og forbedring af teamets effektivitet er effektive. Men også for at holde styr på, hvordan deres handlinger påvirker udviklingsteamet. Det vil sige, hvordan de former medarbejderens brugeroplevelse (UX). Så i denne artikel introducerer vi statistik og målinger, som Scrum Masteren bør holde øje med.
Statistik og målinger vigtige for Scrum Masteren – indholdsfortegnelse:
- Måling af resultaterne af udviklingsteamets arbejde
- Overvågning af medarbejdernes brugeroplevelse udviklere
- Sammenfatning
Måling af resultaterne af udviklingsteamets arbejde
De mest almindeligt anvendte statistikker og målinger, som Scrum Masteren bør holde øje med, er dem, der beskriver tempoet og flowet i opgaveudførelsen. Disse er Burnup Chart, Burnup Chart og Cumulative Flow Chart. Disse målinger vurderer både produktudvikling og teamets effektivitet. Hver enkelt giver mulighed for at nærme sig disse spørgsmål fra en anden vinkel, så det er en god idé at vise dem sammen. De er nyttige værktøjer til at vurdere fremskridt på forskellige skalaer, både under en Sprint og i hele produktudviklingsprocessen.
Burndown Chart
Burndown chart viser Scrum Masteren og udviklingsteamet, hvor meget arbejde der er udført, og hvor meget der er tilbage at gøre. X-aksen viser den tid, der er tilbage til at fuldføre arbejdet. Y-aksen viser mængden af arbejde, der er tilbage at udføre, som var planlagt i Sprint Backlog eller Product Backlog.
Dette diagram hjælper også med at bestemme hastigheden af udviklingsteamet, som vi også vil dedikere en separat artikel til. Her vil vi kun nævne, at det er en gennemsnitlig mængde arbejde udført i løbet af en Sprint.
Dette enkle værktøj gør det muligt for Scrum Masteren ikke kun at se hvor effektivt teamet arbejder. Det hjælper også med at besvare spørgsmål:
- Hvilken del af arbejdet er allerede blevet afsluttet?
- Hvor mange opgaver er der tilbage at fuldføre?
- Hvor lang tid vil det tage at udvikle produktet?
Når man bruger Burndown Chart, skal Scrum Masteren huske, at det ikke er det eneste værktøj til statistisk at vurdere teamets fremskridt. Det fungerer bedst for projekter, hvor arbejdsomfanget er fast og kendt. Det fungerer ikke godt med at skabe meget innovative løsninger med en ny klient. Så kan mængden af arbejde, der skal udføres i hele projektet – det vil sige indholdet af Product Backlog – ændre sig betydeligt i løbet af projektet, hvilket gør det svært at bruge Burndown Chart.
Burnup chart
Burnup Chart er det modsatte af Burndown chart, der blev diskuteret ovenfor. Her viser Y-aksen også mængden af arbejde, der er tilbage at udføre. X-aksen viser derimod afslutningstiden, der udtrykkes enten i antal Sprints eller i datoer.
Dog bruger Scrum Masteren Burnup Chart til et lidt andet formål. Dette skyldes, at det ikke kun hjælper med at måle produktets fremskridt og teamets fremskridt. Denne måling vurderer også, hvordan arbejdsomfanget i et projekt ændrer sig over tid. Derfor fungerer det godt for projekter med variabelt omfang.
Burnup Chart er også et planlægningsværktøj, der bliver mere effektivt over tid. Det giver svar på spørgsmålet om, hvor meget arbejde udviklingsteamet forventes at udføre i den næste Sprint.
Cumulative Flow Diagram
Den tredje type diagram, der er meget frugtbar i Scrum Masterens arbejde med udviklingsteamet, er Cumulative Flow Diagram. Det indeholder analysen af hvor stabilt tempoet og produktiviteten i udviklingsteamet er. Layoutet af dets akser er det samme som Burnup Chart, så det kaldes ofte for en mere kompleks version af det.
Dog er Cumulative Flow Diagram ikke kun til at bestemme antallet af opgaver, der er afsluttet i en given tidsperiode. Det tager også højde for antallet af opgaver, der venter i køen til udførelse. Takket være dette muliggør det at diagnosticere de såkaldte “flaskehalse” – øjeblikke i processen, der bremser skabelsen af et produkt.
Denne meget diagnostiske funktion gør det til et af de mest nyttige målinger i hænderne på Scrum Masteren. Dette skyldes, at det gør det muligt at reorganisere arbejdet på en måde, så styrken af udviklingsteamet fordeles anderledes og undgår nedetid.
Overvågning af medarbejdernes brugeroplevelse udviklere
Regelmæssig og omhyggelig vedligeholdelse og analyse af statistikker er en væsentlig del af en effektiv Scrum Masters arbejde. Dog skal han/hun først have fokus på medarbejdernes brugeroplevelse hos udviklerne, dvs. den måde, de opfatter arbejdet i Scrum Teamet. Det er dog ikke kvaliteten af målingerne, der afgør, men den måde, hvorpå Scrum Masteren bruger dem.
Hvis statistikkerne opbevares i overensstemmelse med Scrums principper – de er gennemsigtige, offentlige og forståelige for de involverede udviklere – kan de være en måde at motivere teamet til at arbejde mere effektivt eller belønne dem for gode resultater. Dog kan statistikker fungere som et værktøj til at lægge pres på udviklingsteamet. Så bliver deres indikationer en generator af anklager og harme. De kan bidrage til at forringe teammoralen og ødelægge samarbejdspraksis.
Den anden vigtige faktor i medarbejderoplevelsen hos udviklere, som Scrum Masteren, der arbejder med statistiske værktøjer, skal tage sig af, er måden at styre deres tid på. Dette skyldes, at Scrum Masteren har brug for at have nok tid til at tage sig af udviklingsteamet. Af denne grund, i tilfælde af et stort projekt, er det værd at overveje at inkludere en ekstra person i Scrum Teamet. Han/hun vil fungere som projektleder og tage sig af målingerne. Takket være dette vil det aflaste Scrum Masteren – og til en vis grad Product Owneren – fra opgaver, der distraherer ham fra at arbejde med udviklingsteamet.
Statistik og målinger – sammenfatning
Scrum Masteren skal holde øje med de grundlæggende statistikker, der beskriver arbejdet i udviklingsteamet. Deres dygtige fortolkning øger chancen for hurtigt at opdage problemer i teamets arbejde og reagere på dem. Dog er mere vigtigt end at holde styr på diagrammerne, hvad Scrum Masteren gør med dem. De bør ikke betragte målingerne som et værktøj til at evaluere teamet, men snarere betragte dem som et nyttigt hjælpemiddel til at motivere teamet og diagnosticere deres egen måde at gøre tingene på. Dette skyldes, at målinger kun vil være nyttige værktøjer, hvis de hjælper med at lette teamets og produktforbedringsprocesserne.
Hvis du kan lide vores indhold, så bliv en del af vores travle bier-fællesskab på Facebook, Twitter, LinkedIn, Instagram, YouTube.
Caroline Becker
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.
Scrum Guide:
- Ordbog over grundlæggende termer, roller og begreber
- Hvad er Scrum?
- Scrum værdier
- Hvordan implementerer man Scrum i din virksomhed?
- Scrum Team - hvad er det, og hvordan fungerer det?
- Hvem er en Product Owner?
- De mest almindelige fejl hos Product Owner
- Hvem er Scrum Masteren?
- De mest almindelige fejl hos Scrum Master
- Hvilke statistikker og målinger bør Scrum Masteren følge?
- Udviklingsteam i Scrum
- De mest almindelige fejl hos udviklere
- Scrum artefakter
- Skalering af Scrum
- Sprint Backlog
- Hvad er produktbackloggen?
- Hvad er brugerhistorier?
- At skabe den bedste User Story med INVEST
- De mest almindelige fejl i User Stories
- Brugerhistorie Acceptkriterier
- Estimering og Story Points i Scrum
- Planlægningspoker
- Team Estimeringsspil
- Definere inkrement
- Scrum begivenheder
- Hvad er et Burndown-diagram?
- Fordele og ulemper ved burndown-diagrammet
- Kanban-tavler i Scrum og Scrumban
- Hastighed i Scrum - Udviklingsteamets hastighed
- Daglig Scrum
- Sprintplanlægning
- Sprintgennemgang
- Hvad er en Sprint Retrospektiv?
- Almindelige fejl under en Sprint Retrospektiv
- Produkt Backlog pleje
- Hvordan opretter og fortolker man et burndown-diagram?