Scrum Guide | 23. Story Points og Estimering i Scrum

I dagens artikel dækker vi emnet Estimering og Story Points i Scrum. At lave estimater i Scrum hjælper med at forudsige kompleksiteten og den tid, der kræves for at fuldføre opgaver. Ved at analysere fortiden forudser hele Scrum-teamet kollektivt, hvad fremtiden bringer.

Derfor, jo mere erfaren Scrum-teamet er, jo mere præcise er deres estimater. Teamet samarbejder også om at fastlægge den estimerede tid til at fuldføre opgaverne under Sprint Planlægning, idet de husker, at det ikke er et endeligt engagement, men en forudsigelse. Dens nøjagtighed afhænger af adskillige variable, der konstant gennemgår uforudsigelige ændringer og uventede omstændigheder. Heldigvis inkluderer Scrum-metodologien teknikker og værktøjer til at lette en vis grad af sikkerhed, og i dag vil vi diskutere dem i detaljer, så du kan forstå og anvende dem med det samme!

Story Points og Estimering i Scrum – indholdsfortegnelse:

1. Introduktion
2. Vigtigheden af Story Points i Scrum
3. Relative estimeringsteknikker
4. Sammenfatning

Introduktion

Ved hver Sprint Planlægning præsenterer Product Owner nye User Stories for teamet. Product Owner vælger dem fra Product Backlog til implementering i den næste Sprint. Derefter estimerer Scrum-teammedlemmerne i fællesskab arbejdsbyrden, der er nødvendig for at fuldføre denne nye bunke af opgaver. Denne type opgave er en estimering, kravestimering.

Det ville synes, at den simpleste måde er at definere den tid, der er nødvendig for at fuldføre opgaven i timer eller dage. Men praksis og forskning udført siden 1940’erne viser noget andet. Mennesker er ude af stand til præcist at estimere den tid, der kræves for at fuldføre selv meget veldefinerede opgaver. Desuden afhænger antallet af timer, der er nødvendige for at fuldføre en opgave, af, hvem der udfører opgaven, og hvad der er – eller ikke er – blevet gjort før. Dette er grunden til, at Scrum typisk bruger enheder kaldet Story Points.

Vigtigheden af Story Points i Scrum

Hvert udviklingsteam sætter værdien af en Story Point i praksis ved at trække på erfaring og størrelsen af individuelle opgaver, dvs. følge princippet om empirisme. Ofte, under Sprint Planlægning, vælger Scrum Master en eller flere prøver af afsluttede User Stories, som fungerer som et referencepunkt for at bestemme værdien af de User Stories, der skal udvikles.

Derfor kan du ikke tildele værdier i Story Points uden konteksten. For eksempel, hvis den første opgave tildeles en værdi på 10, vil efterfølgende opgaver blive vurderet i forhold til den som enten større eller mindre. På denne måde, inden for et Scrum Team-projekt, er alle opgaver i Product Backlog relateret til hinanden. Dette betyder, at lignende opgaver udført af et udviklingsteam vil modtage et lignende antal point.

Story Points er relative enheder. Dette betyder, at:

1. Værdien af Story Points relaterer sig kun til de opgaver, der udføres af et bestemt Scrum Team. Story Points beskriver hastigheden af fuldførelsen af opgaverne for et team. Med andre ord, en User Story, der er estimeret til 10 Story Points af Team A, kan få 50 af Team B. Dette skyldes, som vi nævnte, at deres værdi er relativt beregnet i forhold til andre opgaver udført af det team og deres erfaring med lignende opgaver.
2. Værdien af Story Points, der er fuldført i en Sprint, kan ikke være grundlag for at sammenligne præstationen af to Scrum Teams. For at undgå fejl i styringen af Scrum-projekter er det vigtigt at huske, at hastigheden af et udviklingsteam udtrykt i Story Points udført i en Sprint ikke kan bruges til at sammenligne præstationen af to teams. Dette skyldes, at de kunne udføre det samme arbejde i parallelle Sprints, som det ene team estimerede til 10 og det andet til 50 Story Points.

Det bør heller ikke glemmes, at estimeringen indeholder mange ukendte elementer og foretages på baggrund af ufuldstændige data. Af denne grund kan forudsigelserne fra selv et meget erfarent Scrum Team nogle gange være meget forskellige fra den reelle indsats, der er nødvendig for at fuldføre en User Story.

Relative estimeringsteknikker

Hvad er de mest effektive estimeringsteknikker i Scrum? Der er ikke én metode, der passer til alle, som fungerer for hvert team.

Blandt estimeringsteknikkerne inden for agile metoder er de mest almindelige:

• Planning Poker. Denne mest populære relative metode tager et kortspil til at beregne mængden af arbejde, der skal udføres for at fuldføre en opgave. Dens detaljerede regler og proces vil vi dække i en separat artikel.
• Team Estimation Game. Denne involverer tildeling af udførelsen af User Stories i en given Sprint med passende numeriske værdier valgt fra Fibonacci-sekvensen. Vi har også viet en separat artikel til det.

Scrum afviser derimod den klassiske absolutte estimeringsmetode fra den traditionelle projektledelsesmetodologi. Den måde, det estimerer opgaver på, er ved på forhånd at definere person-måneder, varighed og omkostninger for hele projektet. Dette er en lang proces, der er svær at implementere og kræver deltagelse af eksperter, der har tendens til at etablere rationale og adfærdskodeks, men ikke tager handling, som ikke nødvendigvis vil udføre de opgaver, hvis værdi de estimerede. Med andre ord, det er ikke kun kedeligt, men også meget ineffektivt.

Story Points og Estimering – Sammenfatning

Estimering er en meget vigtig færdighed, der kendetegner alle modne Scrum Teams. At estimere den tid og indsats, der kræves for at fuldføre individuelle opgaver, er blevet hovedfokus for mange relative estimeringsteknikker som Planning Poker eller Team Estimation Game.

User Stories med Story Points er endnu en effektiv målemetode, vi har beskrevet, forhåbentlig giver vores læsere nogle nyttige værktøjer. Det er dog vigtigt at huske, at deres tal kun relaterer sig til de bestemte opgaver, der udføres af Scrum Team. Derfor kan antallet af Story Points ikke blive grundlaget for at sammenligne hastigheden af forskellige udviklingsteams.

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