Start / Agil inspiration / Estimering och story points

Estimering och story points

Även i agila sammanhang vill vi ha en gissning om framtiden och en idé om vilka saker som kan bli klart när. Vi vill veta hur mycket jobb vi har i vår backlog. Vi behöver även veta hur stora olika arbetspaket är för att kunna prioritera. Om något kommer att ta väldigt lång tid kanske det ska vänta till förmån för annat som går fortare men som ändå ger mycket värde. Vi behöver alltså kunna estimera backloggen.

Relativ estimering​

Normalt brukar vi ju estimera i timmar. Det finns dock stora nackdelar med det:

  • Det är svårt att ge ett exakt antal timmar, vi behöver då göra mycket förstudie vilket tar tid. Dessutom är det ändå risk att estimeringen inte stämmer då det är så svårt att förutse vilka problem som kommer uppstå.
  • Det är svårt att få en utvecklare att ge en grov uppskattning då det ofta blir taget för exakt vetenskap. Blir man tillfrågad att ge en grov uppskattning mellan tummen och pekfingret och säger ca 40 timmar, blir 40 timmar lätt ett löfte som anses vara noggrant underbyggt. Om arbetet sedan tar 60 timmar finns det risk för att det blir missnöje.​
  • En estimering i timmar beror också väldigt mycket på vem som ska göra jobbet. Är det en erfaren person går det troligen minst dubbelt så fort som om det är någon oerfaren.​
  • Relativ estimering fungerar mycket bättre och bygger på att man jämför olika arbetspaket med varandra. Det är ganska enkelt att säga vilka av nedan produkter som är tar väldigt mycket tid, ganska mycket tid eller lite tid att utveckla. Vi kan uppskatta dem i t-shirtstorlekar. Datorn och telefonen är troligen ”XL” då dessa tar väldigt mycket tid att utveckla medan fjärrkontrollen är ”S” och skärmen kanske ”S” eller ”M”. De som utvecklar denna typ av produkter kan ganska enkelt bedöma detta. ​
  • Det spelar då ingen roll vem som ska göra jobbet, relationen mellan dem är ändå den samma. Ingen kommer heller känna att man lovar ett visst antal timmar. Denna typ av estimering gå snabbt att göra och passar bra när vi vill estimera många olika sker i vår backlog.​

Story points​

Vad är då storypoints? Vi skulle kunna köra helt med S, M, L XL och XXL men t-shirt storlekarna har en nackdel, de går inte att addera ihop. Om vår Backlog består av 10st S, 4st M, 5st L och 3st XL, hur lång tid tar det då att leverera alla dessa om vi normalt brukar leverera 3 st S och 4st M i varje sprint?? Vi får helt enkelt göra om t-shirt storlekarna till siffror. S kan få vara 3 story points och M kan få vara 5. Vi använder Fibonacciskalan då den innehåller lagom siffror för att ersätta t-shirts. Den ser ut så här: 1, 2, 3, 5, 8, 13, 20, 40 och 100. Det är en modifierad Fibonacciskala och den fungerar utmärkt för våra stories. Vi kommer efter ett par sprintar kunna se hur många storypoints vi levererar i genomsnitt och den siffran kan vi använda för att uppskatta Backloggen framåt.​

Story point övning​

Ett väldigt bra sätt att komma igång med Story Points är att köra nedan beskrivna storypointövningar.

  1. Skriv ut ett antal redan avklarade stories som teamet känner till väl. Be dem rangordna dem i storleksordning och sätta upp på en whiteboard, se de gröna lapparna i bilden nedan. 
  2. Skapa kolumner utifrån dessa stories och sätt story points på varje kolumn. Fyll på med kolumner enligt Fibonacciskalan. 
  3. Ta sedan nya stories som ligger i Backloggen, de rosa lapparna i bilden, och be teamet jämföra dem med de som redan sitter där. När teamet är överens sätter ni upp dem i respektive kolumn. Fortsätt tills ni har ganska många stories på whiteboarden.

Har du frågor om agil organisation?