Story points i utveckling — vad är det, bedömningsskalor och tillämpning
Story points — är relativa måttenheter för uppgiftskomplexitet inom agila utvecklingsmetodiker. Till skillnad från timmar tar story points inte bara hänsyn till tid, utan även till komplexitet, risker och osäkerhet i uppgiften. Enligt Scrum.org, 2023, missar team som använder relativ bedömning i story points sprintdeadlines 25% mer sällan jämfört med team som bedömer i timmar.
Huvudpunkter
- Story points — relativa enheter för uppgiftskomplexitet, inte knutna till tid.
- Huvudskalor — Fibonacci (1, 2, 3, 5, 8, 13, 21) och linjär (1, 2, 3, 4, 5).
- Velocity — antalet story points som ett team slutför under en sprint, används för prognoser.
- Främsta fördelen — story points är inte beroende av en specifik utvecklare och återspeglar komplexiteten för teamet.
- Nyckelregel — referensuppgiften bestämmer skalan: teamet kommer överens om vad 1 story point är.
Vad är story points?
Story points — är ett mått på uppgiftskomplexitet som används i Scrum och andra agila metodiker. Teamet bedömer varje uppgift inte i timmar, utan i relativa enheter: “den här uppgiften är dubbelt så komplex som referensen”. Detta tillvägagångssätt neutraliserar skillnaden i hastighet mellan olika utvecklare och fokuserar på komplexitet.
Termens ursprung
Begreppet story point uppstod i början av 2000-talet i samband med populariseringen av Scrum. En av de första som beskrev metoden var Ron Jeffries inom ramen för Extreme Programming (XP). Idén var att gå bort från bedömning i “mantimmar”, som alltid är inexakt, till relativ komplexitet som teamet bestämmer kollektivt. Idag är story points industristandard för agila team.
Faktorer som beaktas i story points
Vid bedömning med story points tar teamet hänsyn till tre faktorer: arbetsvolym (mängd kod, skärmar, logik), komplexitet (tekniska utmaningar, ny teknik) och osäkerhet (otydliga krav, risker). Ett story point kan betyda “enkel uppgift utan risker”, och 8 — ”komplex uppgift med hög osäkerhet”.
Story point-skalor: hur man väljer
Valet av story point-skala påverkar bedömningens noggrannhet och planeringens bekvämlighet. Den mest populära skalan är Fibonacciföljden, men det finns alternativ.
| Skala | Värden | Fördelar | Nackdelar |
|---|---|---|---|
| Fibonacci | 1, 2, 3, 5, 8, 13, 21 | Naturlig ökning av spridning vid stora uppgifter | Komplicerad för nya team |
| Linjär | 1, 2, 3, 4, 5 | Enkel och begriplig | Ingen spridning för stora uppgifter |
| Potens | 1, 2, 4, 8, 16, 32 | Maximal spridning vid stora uppgifter | Stora uppgifter svåra att särskilja |
| T-Shirt | S, M, L, XL | Snabb grov bedömning | Oexakt, kräver konvertering |
Varför Fibonacci? Psykologin bakom skalan
Fibonacciföljden valdes inte slumpmässigt. Skillnaden mellan 1 och 2 är minimal (50%), men mellan 13 och 21 — betydande (62%). Detta speglar verkligheten: små uppgifter bedöms mer exakt, stora — med större spridning. När en uppgift bedöms till 21 story points förstår teamet: “vi vet inte hur lång tid det tar, men definitivt mer än 13”. Fibonacciskalan förhindrar falsk noggrannhet.
Referensuppgift — skälans grund
För att skalan ska fungera kommer teamet överens om en referens: “uppgift X — 1 story point”. Vanligtvis väljs en enkel, välkänd uppgift som referens: “lägg till ett textfält på skärmen” eller “åtgärda ett bug av typen skrivfel”. Alla andra uppgifter bedöms i förhållande till referensen. Utan referens förlorar story points sin mening — alla förstår enheten olika.
Teamets velocity och prognoser
Velocity (teamets hastighet) — det genomsnittliga antalet story points som teamet slutför under en sprint. Detta är den viktigaste metriken för att prognostisera projektdeadlines.
Hur velocity beräknas
Velocity beräknas baserat på slutförda uppgifter: story points för alla uppgifter som teamet hunnit slutföra (definition of done uppfylld) summeras. Ofullständiga uppgifter räknas inte. För noggrannhet tas genomsnittet av de senaste 3-5 sprintarna. Om teamet till exempel slutfört 20, 22, 18 och 24 story points under de senaste 4 sprintarna är velocity = 21 sp.
Prognoser via velocity
Genom att känna till velocity och den totala backlogvolymen i story points kan antalet sprintar till release prognostiseras. Om det till exempel finns 210 story points i backloggen och velocity = 21, krävs 10 sprintar. Detta är en grov prognos som förfinas under arbetets gång. Viktigt: velocity är ett genomsnitt, inte ett åtagande. Planera enligt nedre gränsen (18 sp), inte genomsnittet.
Hur man ökar velocity
Velocity kan inte ökas genom order — det är ett symptom på processernas hälsa. Hållbar ökning av velocity uppnås genom: minskning av teknisk skuld, förbättring av code review-processer, minskning av kontextväxlingar, automatisering av testning och CI/CD. Viktigt: olika teams velocity kan inte jämföras — varje team definierar story points på sitt eget sätt.
Story points vs timmar: vad och när man använder
Story points och timmar har olika syften och valet mellan dem beror på sammanhanget. Erfarna team använder båda metoderna för olika uppgifter.
När story points fungerar bättre
Story points är oumbärliga för sprintplanering: de är inte beroende av vem som utför uppgiften. En junior kan göra 2 sp per dag, en senior — 4 sp, men bedömningen av uppgiften förblir 2 sp för båda. Story points möjliggör spårning av teamets produktivitet utan att jämföra utvecklare. Detta minskar politisk press och förbättrar teamets atmosfär.
När timmar är nödvändiga
Timmar behövs för externa åtaganden: kontrakt, budgetar, rapporter till kunden. Kunden vill veta inte “8 story points”, utan “3 veckor”. För konvertering av story points till timmar används historical conversion rate: teamet vet att 1 sp = ungefär 4 timmars arbete. Konverteringen måste vara transparent och baserad på data, inte på gissningar.
Kombinerad metod
Många team använder en kombinerad metod: uppgifter bedöms i story points för sprintplanering, sedan konverterar chefen dem till timmar/dagar för extern rapportering. Det är viktigt att inte blanda två system i en process: antingen bedömer du i story points och härleder tid från velocity, eller så bedömer du direkt i timmar.
Vanliga misstag vid arbete med story points
Införandet av story points åtföljs ofta av misstag som upphäver fördelarna med relativ bedömning. Här är de vanligaste.
Koppla story points till tid
Det vanligaste misstaget — teamet kommer överens: “1 sp = 4 timmar”. I detta fall förlorar story points sin mening och förvandlas till timmar under ett annat namn. Story points måste vara relativa, inte knutna till tid. Om uppgift A är dubbelt så komplex som uppgift B får den 2 sp, oavsett hur många timmar det tar.
Post-factum-bedömning
När en uppgift bedöms efter att den utförts — är detta inte en bedömning, utan ett konstaterande. Story points måste tilldelas innan arbetet påbörjas, i ögonblicket av maximal osäkerhet. Post-factum-bedömning snedvrider velocity och ger ingen nytta för planering. Dessutom skapar den en falsk känsla av noggrannhet.
Jämföra velocity mellan olika team
Att jämföra velocity för team A och team B — en meningslös övning. Varje team definierar referens och skala på sitt eget sätt. För ett team är 1 sp en enkel uppgift på en timme, för ett annat — en uppgift på en dag. Endast velocity för samma team i dynamik kan jämföras: ökar eller minskar den.
Inkonsekvent skala
När olika uppgifter med samma komplexitet får olika story points och mer komplexa — färre, bryts skalan. Teamet måste regelbundet kalibrera skalan: var 3-6 sprint retrospektivt kontrollera hur väl bedömningarna motsvarade den verkliga komplexiteten. Detta förbättrar konsekvensen i bedömningarna.
Vanliga frågor
Hur många timmar är ett story point?
Story points har ingen fast motsvarighet i timmar. Det är en relativ enhet: 1 sp = komplexiteten hos referensuppgiften. För konvertering till timmar, använd ditt teams historical conversion rate: dividera det genomsnittliga antalet arbetade timmar under en sprint med velocity. Vanligtvis är 1 sp = 4-8 timmar, men detta är individuellt för varje team.
Kan story points användas i Kanban?
Ja, story points kan användas i Kanban, men med förbehåll. I Kanban finns inga fasta sprintar, så velocity beräknas inte per sprint, utan per vecka eller månad. Kanban-team använder ofta istället för story points Cycle Time — tiden för en uppgift från början till slut. Valet beror på teamets specifika egenskaper.
Vad gör man om teamet inte kan komma överens om bedömningen?
Om bedömningarna skiljer sig (en ger 3 sp, en annan — 13), är detta en signal om att uppgiften inte är väl förstådd. Dekomponera uppgiften i mindre delar. Diskutera risker och osäkerheter som olika utvecklare ser. Om uppgiften är stor — bedöm den som Spike (undersökning på 2-4 dagar) istället för story points.
Hur slutar man bedöma i timmar och går över till story points?
Övergången tar 3-6 sprintar. Börja med att välja skala (Fibonacci — safest choice) och bestämma en referensuppgift. Håll 2-3 Planning Poker-sessioner. Efter varje sprint, beräkna velocity. Konvertera inte story points till timmar — låt teamet vänja sig vid det nya systemet. Efter 3 sprintar kommer du att se hur mycket planeringen har förbättrats.
Ändras bedömningen av en uppgift i story points efter att den slutförts?
Nej, bedömningen ändras inte. Story points är en preliminär bedömning av komplexitet som görs innan arbetet påbörjas. Efter att uppgiften slutförts förblir bedömningen densamma, även om den faktiska arbetsinsatsen var annorlunda. Att ändra bedömningen post-factum snedvrider statistiken och gör prognoser meningslösa. Analysera avvikelser på retrospektiven, men ändra inte bedömningen i efterhand.
Sammanfattning
- Story points — relativa komplexitetsenheter, inte knutna till tid, grunden för Agile-bedömning.
- Huvudskalor — Fibonacci (rekommenderas), linjär, potens, T-Shirt sizing.
- Velocity — antal story points per sprint; nyckelmetrik för deadline-prognoser.
- Story points vs timmar — story points för sprintplanering, timmar för externa åtaganden.
- Vanliga misstag — koppling till tid, post-factum-bedömning, jämförelse av team, inkonsekvent skala.
- Referensuppgift — grunden för skalan; utan den förlorar story points sin mening.
- Främsta fördelen — story points är inte beroende av utföraren och möjliggör fokus på teamets produktivitet.
Vi utvecklar en mobil applikation nyckelfärdigt
IT Sectr skapar iOS- och Android-applikationer för startups och företag sedan 2017. Vi ger dig råd och föreslår den bästa lösningen.
Läs också