programmeraren.blogg.se

Alla som har jobbat i Scrum, och det har väl de flesta av oss vid det här laget, har säkert ställt sig frågan: Vilken uppgift ska jag ta mig an härnäst?

Den mer generella frågan, som den här bloggposten vill ge ett svar på, är: Hur ska uppgifterna i backloggen prioriteras mot varandra?

Det här brukar vara mer konst än vetenskap och man gör det lite på känn; vid behov, när det finns tid över, eller vid särskilda prioriteringsmöten. Aspekter som brukar vägas in är hur lång tid uppgiften tar, hur viktig den är och kanske även dess svårighetsgrad.

För att försöka lösa det här problemet en gång för alla har jag identifiera fem olika kriterier som jag anser bör vägas in i bedömingen. Vidare har jag rangordnat dessa kriterier mot varandra och slutligen har jag satt ihop dem till en formel som tar hänsyn till rangordningen och som ger en totalsumma att prioritera efter, utifrån hur många poäng man satt på varje dimension.

Alltså: Istället för att sätta upp fingret i luften och känna efter hur uppgifterna bör prioriteras, bedömmer man dem enskilt i fem olika dimensioner och räknar sedan fram en inbördes rangordning.

De fem kriterierna är som följer:

1. Funtamentalitet
   - det första kriteriet har att göra med hur central för systemets ändamål en uppgift är. Jag anser detta vara det viktigaste kriteriet. Ett system bör byggas inifrån ut. Om inte kärnfunktionaliteten fungerar tillfredställande spelar det mindre roll hur bra kringfunktionerna är. Lägger man för stor vikt vid kringfunktioner så kanske man utvecklar fel system och borde istället utveckla ett system där kringfunktionerna är centrala. Alltså; börja med fundamental funktionalitet och gå sedan mot allt mer perifera funktioner när det mer basala finns på plats och fungerar som det ska

2. Enkelhet
   - För att undvika att bygga på den tekniska skulden så bör man som nummer två värdera hur en uppgift påverkar systemets totala komplexitet. Om det finns uppgifter som minskar den totala komplexiteten eller åtminstone inte ökar den så bör man ta dem före uppgifter som ökar komplexiteten. Jobbar man i den riktningen så skapar man allt hållbarare fundament som kan bära upp en allt större funktionell överbyggnad. Annorlunda uttryckt: De uppgifter som idag adderar mycket komplexitet kan imorgon addera liten eller ingen komplexitet om man först har förstärkt och renodlat fundamenten/koncepten.

3. Värde
   - Först på tredje plats har jag rankat det som vid första anblicken kan tyckas vara det viktigaste kriteriet, nämligen hur stort värde en funktion adderar till systemet. Anledningen är att ett IT-system är som ett isberg; den lilla synliga toppen motsvarar funktionalitet som ger ett direkt värde för kunden och allt annat är stödstrukturer som krävs för att bära upp de värdebärande funktionerna. Efter hand som ett system växer sig större och mer komplext minskar den värdebärande funktionalitetens andel av den totala massan. Om man bara satsar på att addera värde så riskerar överbyggnaden att bli större än vad fundamentet kan bära upp och hela systemet kollapsar under sin egen tyngd. Därför bör fundamentalitet och komplexitet värderas över värdeskapande.

4. Svårighetsgrad
   - svårighetsgrad är i stort sett ekvivalent med risk: Risk att man inte hittar någon som är kompetent nog att utföra uppgiften, risk att oväntade problem uppstår under utvecklingen, risk att funktionen skapar nya buggar, och risk att man har missbedömt någon av de andra kriterierna. Därför bör svårighetsgraden vägas in när man prioriterar uppgifter. Börja med det som är enkelt. Ju längre arbetet framskrider desto mer erfarenhet samlar utvecklarna och ju starkare fundament finns att bygga mer komplicerade funktioner på. Bygger man rätt så tenderar svåra uppgifter som man skjuter på framtiden att te sig allt enklare med tiden och kommer därför prioriteras allt högre, allt annat lika.

5. Tidsåtgång
   - Sist och faktiskt minst väsentlig är tidsåtgången. I de flesta IT-projekt beror en överhängande del av tidsåtgången på att man får betala för gamla synder, det vill säga handskas med teknisk skuld. Det kan röra sig om så mycket om en faktor tio eller en faktor hundra i tidsskillnad mellan att bygga en funktion på ett starkt och väl underhållet fundament och att bygga den på ett svagt och överkomplext fundament. Därför blir tidsåtgången ofta mer en funktion av hur väl underhållet systemet är än en funktion av hur stor uppgiften är. Icke desto mindre bör naturligtvis tidsåtgången beaktas eftersom effektiviteten i utvecklingen totalt sett är en funktion av värde delat med tid.

Man poängsätter alltså varje uppgift efter var och en av ovan beskrivna dimensioner. Sedan summeras poängen, och uppgifter med lägre poäng prioriteras före uppgifter med högre poäng.

För att väga in rangordningen mellan dimensionerna så har de olika skalor, där de viktigare dimensionerna har fler poäng att fördela än de mindre viktiga. Närmare bestämt har Fundamentalitet sju poäng att fördela, Enkelhet sex poäng och så vidare, ner till Tidsåtgång som har tre poäng. Varför en kortare poängskala ger en mindre total vikt i sammanräkningen behöver kanske motiveras. Man kan tänka så här: Differensen mellan minsta och största poäng är mindre ju kortare skalan är, alltså ger en kortare skala en mindre addering till totalsumman. 

Poängskalorna är som följer:

Fundamentalitet:

1: Fundamental
   - utan vilken systemet inte kan köras

2: Essentiell:
  - utan vilken systemet inte är ändamålsenligt

3: Kärnfunktion
 - utan vilka systemet inte kan anses fullt funktionellt

4: Basal funktion
 - utan vilka systemet inte kan anses komplett

5: Extra funktionalitet
 - som lägger till det som behövs i anslutning till det basala och gör systemet fullödigt

6: Nice to have / bra att ha

 - som ytterligare förbättrar systemet

7: Goldplating / Förgyllning
 - som adderar det lilla extra, t ex snyggare layout, grafiska effekter eller arbetsbesparande extra kommandon.

Enkelhet:

-2: Väsentlig förenkling

-1: Viss förenkling

0: Ingen förändring i komplexitet

1: Viss komplexitetsökning

2: Väsentlig komplexitetsökning

3: Mycket stor komplexitetsökning

Värdeskapande

0: Skapar inget direkt värde för användaren (refaktorering)

-1: Litet värde

-2: Medel värde

-3: Stort värde

-4: Mycket stort värde

Svårighetsgrad:

1: Trivialt

2: Enkelt

3: Medel

4: Svårt

Tidsåtgång:

1: Kort (minuter)

2: Medel (någon eller några timmar)

3: Lång (många timmar eller flera dagar)

Genom lite huvudräkning får man snabbt fram att totalsumman som man prioriterar efter kan variera mellan -3 och +17, alltså en total differens på 20; där Tidsåtgång adderar 2, Svårighetsgrad 3 och så vidare, upp till Fundamentalitet som adderar 6 steg.  

Slutligen:

• En uppgift som är mycket svår ska inte utföras direkt, istället ska man titta på vilka förändringar i fundament och arkitektur som krävs för att förenkla uppgiften

• En uppgift som tar lång tid (3 poäng) ska alltid delas upp i mindre uppgifter som värderas var för sig och prioriteras mot övriga uppgifter på nytt

• Uppgifter kan ha beroenden som dikterar i vilken ordning de måste utföras. I sådana fall är det den högst rankade uppgiftens rangordning som bestämmer när andra uppgifter som den är beroende av ska utföras.

• En uppgift som har ett positivt värde om man summerar enkelhet och värde (alltså skapar mer komplexitet än värde) bör tas bort från backloggen. En uppgift där enkelhet + värde = 0 bör noga övervägas vilket problem den löser och om problemet kan lösas på ett sätt som samtidigt ökar systemets samlade värde och potential (= enkelhet). Om inte bör en motivering till varför uppgiften är värd att utföras skrivas in på uppgiftskortet. 

Den ovan beskrivna metodiken / algoritmen är förmodligen lite för hardcore för de flesta Scrum/Kanban-projekt, men i stora projekt där prioritering mellan många uppgifter under tajta tidsramar blir ett stort huvudbry för projektledare och scrummästare kanske den kan tjäna som inspiration, eller rent av går att tillämpa rakt av.