Mange Scrum-teams leder efter en måde at tale om størrelse på arbejde uden at låse sig fast på præcise tidsløfter. Her passer story points godt ind, fordi de giver et fælles sprog om indsats og usikkerhed, også når I ikke har prøvet opgaven før.
Samtidig bliver story points ofte misforstået. Især når point bliver behandlet som “skjulte timer”, eller når de ender som et styringsværktøj til at vurdere mennesker. Lad os få begrebet på plads og gøre det brugbart i praksis.
Hvad måler et story point egentlig?
Et story point er en abstrakt måleenhed til relativ estimering. Relativ betyder, at I vurderer en brugerhistorie i forhold til andre historier: “Er den her mindre, på niveau med, eller større end den historie, vi kender?”
— Du kan få dem tilsendt herunder! —
Pointet er ikke at finde den “rigtige” værdi i sig selv. Pointet er at nå til en fælles vurdering af, hvor stor indsatsen er, og hvad der gør arbejdet svært eller risikofyldt.
I praksis bruger mange teams story points på Product Backlog Items, typisk user stories, men det kan også være tekniske opgaver, spikes eller refaktorering, hvis jeres Definition of Done og arbejdsform understøtter det.
Story points er ikke timer (og det er hele pointen)
Timer er en absolut enhed. Én time er altid én time. Story points er en team-defineret skala, der handler om relativ størrelse, ikke om tid.
Det er fristende at lave en omregning, fx “1 point = 2 timer”. Det føles trygt, men det fjerner de vigtigste fordele: at point kan rumme usikkerhed, og at de kan bruges på tværs af personer med forskellig erfaring.
En senior kan løse noget hurtigt, mens en junior bruger længere tid, selvom opgaven objektivt set er “den samme”. Med point kan I stadig blive enige om størrelsen uden at diskutere individuelle hastigheder.
Hvilke faktorer indgår i et estimat?
Når et team giver story points, blander I ofte flere dimensioner sammen. Det er helt normalt, så længe I gør det konsekvent.
Hent vores bøger og skabeloner herunder
De typiske ingredienser er:
- Kompleksitet
- Mængden af arbejde
- Risiko og usikkerhed
- Afhængigheder
- Kravklarhed og behov for afklaring
En vigtig detalje: To opgaver kan tage samme tid, men få forskellige point, hvis den ene er teknisk usikker eller har mange afhængigheder.
Sådan etablerer I en fælles skala i teamet
Story points virker bedst, når teamet har et par “ankre”, som alle kender. Et anker er en referencehistorie, hvor I er enige om pointtallet, og som I kan sammenligne nye items med.
Start simpelt. Vælg 2-3 historiske historier, som I husker tydeligt, og brug dem som pejlemærker.
En brugbar tilgang er:
- Vælg en meget lille historie og kald den 1 point
- Vælg en “helt almindelig” historie og kald den 3 eller 5 point
- Vælg en tydeligt stor historie og kald den 8 eller 13 point
Efter et par sprints kan I kalibrere. Ikke ved at “rette” gamle tal, men ved at blive skarpere på, hvad I mener, når I siger 5 eller 8.
Planning Poker som fælles estimering
Planning Poker er en enkel måde at få alle stemmer i spil på uden at lade den mest erfarne sætte tallet først.
Flowet er typisk:
- Product Owner præsenterer historien og acceptkriterier
- Teamet stiller opklarende spørgsmål
- Kort fælles snak om løsning, risici og afhængigheder
- Alle vælger et kort i stilhed
- Alle vender kort samtidig
- Teamet taler om de største forskelle og stemmer igen
En god tommelfingerregel er at timeboxe. Et estimat skal være et groft skøn, ikke en designworkshop. Hvis I ikke kan estimere efter et par runder, er det ofte et signal om, at historien er for uklar eller for stor og skal brydes ned.
Hvad betyder tallene på kortene?
Mange teams bruger en Fibonacci-lignende række, fordi springene bliver større, når arbejdet bliver mere usikkert: 0, 1, 2, 3, 5, 8, 13, 21 (og nogle gange 34, 50, 100).
Tallene har ikke en universel betydning. Det er jeres interne skala. Alligevel er det praktisk at have en fælles fortolkning, så I undgår at en 8’er betyder “svær” for én person og “mange opgaver” for en anden.
Her er en typisk læsning, som mange teams kan starte med og justere efter behov:
| Story points | Typisk signal i teamet | Hvad gør I ofte med det? |
|---|---|---|
| 0 | Kan ikke vurderes endnu, eller “ingen reel leverance” | Afklar, lav spike, eller fjern |
| 1 | Meget lille og velkendt | Tag flere ind i sprinten |
| 2-3 | Lille til moderat | God standardstørrelse |
| 5 | Mellemstor, lidt uklarhed eller flere trin | Sikr klare acceptkriterier |
| 8 | Stor, flere risici/afhængigheder | Overvej at splitte |
| 13+ | Meget stor, høj usikkerhed | Split næsten altid |
Læg mærke til, at tabellen ikke siger noget om timer. Det er med vilje.
Fra point til plan: velocity og sprintkapacitet
Når I har estimeret i point i nogle sprints, kan I bruge jeres velocity, altså hvor mange point I typisk færdiggør pr. sprint.
Velocity er ikke et mål for, hvor “dygtige” I er. Det er et planlægningssignal.
Hvis I i gennemsnit færdiggør 25 point pr. sprint, kan I:
- lave grov release-planlægning ved at dividere resterende point med 25
- vurdere om sprintmålet er realistisk, når I plukker stories ind
- opdage ændringer i stabilitet, hvis velocity svinger voldsomt
På BlivProjektleder.dk ser vi ofte, at teams får mere ro i planlægningen, når de bruger velocity som en intern rettesnor frem for at forhandle detaljerede timeestimater med interessenter.
Når point bliver brugt forkert
Story points går sjældent galt, fordi talrækken er forkert. Det går galt, når adfærden omkring tallene ændrer sig.
Her er nogle klassiske fejlmønstre, der dræner værdien hurtigt:
- Point som dom over personer: “Hvem leverer flest point?”
- Point som fast tidskontrakt: “8 point betyder altid 3 dage”
- Point som KPI: “Velocity skal stige hver sprint”
- Point som skjult budget: “I har 200 point tilbage, så det bør tage 200 timer”
Hvis point bruges sådan, begynder teams at beskytte sig: de puster estimater op, undgår risiko, og diskussionerne handler mere om tal end om leverancer.
Små greb der får story points til at virke i hverdagen
Det er sjældent nødvendigt at lave store procesændringer. Ofte skal I bare gøre et par ting konsekvent.
Et praktisk sæt vaner kan være:
- Krav før point: Estimér kun historier med klare acceptkriterier
- Split før 13: Hvis I lander på 13 eller 21, så stop og find en måde at dele historien på
- Hold jer til relative sammenligninger: “Er den her mere som vores 3’er eller vores 8’er?”
- Brug uenighed aktivt: Store spænd i kortene er ofte et tegn på skjulte antagelser
- Kalibrér i retrospekt: Kig på et par færdige historier og spørg om skalaen stadig giver mening
Det vigtigste er, at teamet ejer skalaen. Scrum Master faciliterer, Product Owner afklarer, og udviklingsteamet estimerer.
Eksempel: sådan kan et refinement-forløb se ud
I refinement tager I tre historier fra toppen af backloggen.
Den første historie virker lille. Teamet stiller få spørgsmål, alle vælger 2 eller 3, og I lander hurtigt på 3 point. I skriver et par ekstra acceptkriterier ind, fordi I kan høre, at der var to forskellige fortolkninger af “færdig”.
Den anden historie splitter teamet. Nogle vælger 5, andre 13. Når I taler om det, viser det sig, at halvdelen antager, at der allerede findes en API, mens resten ved, at den skal bygges. I beslutter at dele historien: “API-del” og “UI-del”. Estimeringen giver mere mening bagefter.
Den tredje historie ender på 0. Ikke fordi den er gratis, men fordi I reelt ikke kan vurdere den uden at teste en teknisk mulighed. I laver en spike på 2-3 dage og estimerer spiken i point, så den kan planlægges ind som læringsarbejde.
Det mønster gentager sig sprint efter sprint: pointene bliver ikke “perfekte”, men samtalen bliver bedre, og planlægningen bliver mere stabil.
— Du kan få dem tilsendt herunder! —
