Scrum Guide | 34. Hastighed i Scrum – Udviklingsteamets hastighed

Velocity i Scrum hjælper dig med at bestemme den hastighed, hvormed Scrum-teamet fuldfører opgaver. Vi kan definere det som det gennemsnitlige antal Story Points, der er fuldført i en Sprint. Velocity kan også estimere varigheden af et projekt baseret på det arbejde, der allerede er udført. Dette giver dog kun mening for et modent team, der arbejder i et jævnt og stabilt tempo. Tag et kig på, hvad Velocity er, og hvordan du får det til at fungere bedst for dig!

Velocity i Scrum – indholdsfortegnelse:

1. Velocity i Scrum – Introduktion
2. Aktuel og planlagt velocity
3. Vanskeligheder og risici forbundet med Velocity i Scrum
4. Sammenfatning

Velocity i Scrum – Introduktion

Velocity er en valgfri, men populær metode til at måle tempoet for et Scrum-team. Dette skyldes, at en præcist estimeret Velocity muliggør at forudsige, i rimeligt omfang, den tid der er nødvendig for at fuldføre et projekt. Det er dog et mål, der kun kan anvendes på et givet udviklingsteam, som vil udføre opgaver, som det selv har “vurderet” ved hjælp af en velkendt enhed, såsom Story Points, for eksempel.

Velocity for udviklingsteamet præsenteres oftest i form af et Velocity-diagram. På X-aksen er der markeret på hinanden følgende Sprints. På Y-aksen finder vi derimod antallet af Story Points eller andre tilsvarende enheder, der blev fuldført i en given Sprint. Med Velocity-diagrammet får Scrum-teamet et klart overblik over ændringer i tempoet for sit arbejde. Hvis linjen markeret på diagrammet stiger, betyder det, at teamet optimerer sin effektivitet eller reducerer værdien af Story Points. Både Scrum Master og Product Owner bør derfor nøje følge linjen, der viser teamets Velocity.

Aktuel og planlagt velocity

Den aktuelle Velocity for udviklingsteamet beskriver arbejdstempoet i den afsluttede Sprint og beregnes ved slutningen af hver Sprint. Den tager værdien af summen af Story Points for alle fuldførte User Stories. Den aktuelle Velocity for udviklingsteamet giver dig mulighed for at planlægge og estimere med en vis sandsynlighed tempoet for fremtidige opgaver.

Den planlagte Velocity, derimod, estimeres baseret på en gennemsnitsværdi af den aktuelle Velocity. Det kræver antagelsen om, at der ikke sker ændringer i udviklingsteamet. Det er et vigtigt internt værktøj for udviklingsteamet, som på baggrund af det kan vurdere, om samarbejdet i teamet fungerer godt, og om arbejdstempoet opretholdes.

Planlagt Velocity muliggør også, at Product Owner kan forudsige udførelsestiden for veldefinerede User Stories, der er planlagt til udførelse i de efterfølgende Sprints. Dette muliggør mere effektiv pleje af Product Backlog, som vi skrev om i denne artikel. Dog er praksis med at anvende planlagt Velocity til at estimere projektvarigheder ikke så simpel.

Vanskeligheder og risici forbundet med Velocity i Scrum

Velocity i Scrum gives ofte for meget betydning uden at tage højde for følgende faktorer:

• estimere større helheder eller hele projektet – mens udviklingsteamet kan estimere antallet af Story Points, der skal tildeles en specifik opgave, er det meget svært eller umuligt at beskrive større helheder til fremtidig implementering i disse enheder
• ændringer i projektet – enhver ændring i projektet betyder potentielt en ændring i antallet af Story Points, der er nødvendige for at opnå produktmålet. Det kan også være, at opgaver, der allerede er afsluttet, skal ændres eller endda ikke bruges i den endelige version af produktet
• uforudsete hændelser – at forudsige tempoet for fremtidige projekter baseret på dem, der allerede er afsluttet, det vil sige at oversætte aktuel Velocity til planlagt Velocity, kan resultere i præcise estimater. Dog har hvert projekt sine særtræk, og en præcis forudsigelse baseret på historik er normalt umulig.

Sammenfatning

At bruge Velocity som en måling til at evaluere effektiviteten af udviklingsteamet kan medføre, at dets pålidelighed forringes. Det kan også forringe kvaliteten af estimaterne, som vi skrev om i mere detaljeret i denne artikel. For at opnå de bedst mulige resultater i målingerne kan udviklingsteamet overestimere arbejdsintensiteten af opgaver for at øge Velocity. Dette er skadelig, da teamet selv så mister værdifuld information til at foretage forbedringer og planlægge sine opgaver mere præcist.

Velocity i Scrum er primært nyttig som et internt mål, der bruges af udviklingsteamet til at evaluere tempoet for sit arbejde. Dette skyldes, at det gør det muligt at bestemme, hvor mange opgaver det er i stand til at fuldføre i løbet af en enkelt Sprint.

Velocity i hænderne på Product Owner bliver et nyttigt værktøj til at estimere deadlines for større opgaver.

Dog er de største risici forbundet med at bruge Velocity som en måling til at evaluere udviklingsteamet. Dette skyldes, at det kan føre til en nedsættelse af dets troværdighed og endda en bevidst overestimering af dets værdi for at forbedre den eksterne evaluering af Scrum-teamets arbejde.

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