Når en backlog vokser, og alle interessenter kan argumentere for, at netop deres punkt er vigtigt, bliver prioritering let en blanding af mavefornemmelser, højeste stemme og historiske vaner. WSJF er et af de få prioriteringsgreb, der tvinger jer til at tale om værdi som noget, der ændrer sig over tid, og som skal ses i forhold til den indsats, der skal til.
WSJF (Weighted Shortest Job First) bruges ofte i agile miljøer og i SAFe-inspirerede setups, men principperne fungerer også fint i mindre teams og i klassiske projektporteføljer. Det kræver ikke perfekte tal. Det kræver ensartede, relative vurderinger og en disciplineret proces.
Hvad WSJF hjælper dig med
WSJF hjælper jer med at prioritere efter “værdi pr. indsatsenhed”, med en ekstra pointe: værdien er ikke statisk. Hvis noget udsættes, kan værdien falde, eller risikoen ved at vente kan stige. Det er præcis det, WSJF forsøger at indfange via Cost of Delay.
— Du kan få dem tilsendt herunder! —
Metoden er især nyttig når:
- der er flere teams, der kæmper om samme kapacitet
- der er en blanding af kundeønsker, interne forbedringer og teknisk gæld
- I har deadlines, markedsvinduer eller compliance-krav, der flytter sig
WSJF er ikke en erstatning for strategi. Det er en måde at få strategi omsat til et prioriteringssignal, som kan forklares og gentages.
Grundideen: Cost of Delay og jobstørrelse
WSJF beregnes som Cost of Delay divideret med jobstørrelse. Cost of Delay (CoD) består typisk af tre komponenter: forretningsværdi, tidskritikalitet og risikoreduktion eller mulighedsskabende effekt.
Formlerne skrives ofte sådan her:
Cost of delay = Forretningsværdi + Tidskritikalitet + Risikoreduktion/mulighed
WSJF = Cost of delayJobstørrelse
Hent vores bøger og skabeloner herunder
Pointen er enkel: Et initiativ med høj CoD og lav jobstørrelse bør op i køen, fordi I får meget “værdi nu” pr. investeret tid.
Det vigtige er, at I scorer relativt på en fælles skala. Mange bruger Fibonacci (1, 2, 3, 5, 8, 13, 21) for at tvinge klare forskelle frem, men en 1-10 skala kan også fungere, hvis I kalibrerer den.
Sådan scorer I de tre CoD-komponenter
Når teams oplever modstand mod WSJF, skyldes det ofte, at de tre CoD-dimensioner bliver blandet sammen eller tolket forskelligt fra gang til gang. Start med at blive enige om, hvad I mener med hver dimension, og hvordan man typisk argumenterer for en høj eller lav score.
De tre dimensioner kan beskrives sådan her:
- Forretningsværdi: Direkte nytte ved at levere arbejdet, målt relativt til andre emner (omsætning, kundetilfredshed, effektivitet, kvalitet).
- Tidskritikalitet: Hvor hurtigt værdien forsvinder, hvis I venter (deadline, sæson, kontrakt, konkurrence, intern plan).
- Risikoreduktion/mulighed: Hvor meget arbejdet reducerer fremtidig risiko eller muliggør senere leverancer (teknisk gæld, sikkerhed, regulatorisk robusthed, platformsfundament).
En praktisk måde at holde scoring ærlig er at kræve én sætning som begrundelse pr. dimension. Ikke lange business cases, bare en kort “hvorfor”.
Jobstørrelse vurderes separat. Det er ikke “hvor vigtigt det føles”, men hvor meget arbejde det realistisk tager for teamet, der skal udføre det. Brug gerne samme estimator som I allerede bruger (story points, t-shirt sizes oversat til tal, eller estimeret varighed), så I ikke opfinder et nyt system.
Trin for trin: beregn WSJF på en backlog
WSJF virker bedst, når I bruger metoden på en afgrænset mængde arbejde, ikke på alt hvad virksomheden kunne finde på. Vælg en portefølje, et produktområde eller en PI/kvartals-horisont og tag den derfra.
En enkel arbejdsgang ser sådan ud:
- Vælg 10-25 backlogemner, der reelt konkurrerer om den samme kapacitet.
- Aftal en skala (fx 1, 2, 3, 5, 8, 13) og skriv den synligt.
- Scor forretningsværdi for alle emner først (kun denne dimension).
- Scor tidskritikalitet for alle emner derefter.
- Scor risikoreduktion/mulighed som tredje dimension.
- Estimér jobstørrelse til sidst, og beregn WSJF.
Denne rækkefølge (dimension for dimension) gør det lettere at sammenligne “æbler med æbler”. Hvis I scorer ét emne helt færdigt ad gangen, ender teams ofte med at ændre målestokken undervejs.
Et konkret eksempel med tal (og hvorfor det kan overraske)
Antag at I har tre initiativer. Teamet scorer dem på en relativ skala, lægger CoD sammen og dividerer med jobstørrelse. Det giver en prioriteringsrækkefølge, som nogle gange går imod intuitionen, især hvis et stort og vigtigt initiativ viser sig at være “dyrt pr. uge” at udskyde, men endnu dyrere at bygge lige nu.
Her er et eksempel, der viser mekanikken:
| Initiativ | Forretningsværdi | Tidskritikalitet | Risiko/mulighed | CoD (sum) | Jobstørrelse | WSJF (CoD / jobstørrelse) |
|---|---|---|---|---|---|---|
| A | 9 | 8 | 6 | 23 | 5 | 4,6 |
| B | 5 | 5 | 9 | 19 | 2 | 9,5 |
| C | 3 | 3 | 3 | 9 | 3 | 3,0 |
Initiativ B har lavere CoD end A, men er meget mindre. Derfor får B en højere WSJF-score og bør prioriteres først, hvis I følger modellen.
Læg mærke til hvad tabellen ikke siger: den siger ikke, at A er uvigtigt. Den siger, at B giver mere “værdi pr. indsats” lige nu.
Sådan afholder du en WSJF-workshop der giver mening
Det er fristende at gøre WSJF til en regneøvelse i et regneark, men det bedste output er ofte de fælles afklaringer: hvad betyder værdi hos jer, hvilke deadlines er reelle, og hvilke risici er faktisk dyre.
Start med at skabe en ramme, der gør scoring mulig på 60-90 minutter, uden at det bliver en debatklub.
En typisk workshop kan bygges op med disse elementer:
- Klart scope for hvilke emner der må scores
- Fælles skala og et par eksempler på “lav”, “middel” og “høj”
- Tidsbokse pr. dimension
- Aftale om hvem der kan godkende antagelser på stedet
- Synlig opsamling af begrundelser direkte på kortet eller i backloggen
Hvis I har mange afhængigheder, så gør dem synlige før I scorer. WSJF ignorerer ikke afhængigheder, men det er jer, der skal tage højde for dem, når rækkefølgen skal omsættes til en realistisk plan.
Typiske faldgruber og hvordan du undgår dem
WSJF er et stærkt værktøj, men kun hvis I bruger det på den type beslutninger, det er designet til: valg mellem flere gode muligheder under kapacitetsbegrænsning.
Der er nogle klassiske fejl, som går igen:
- Uens skala fra møde til møde: Kalibrér med 2-3 “referenceemner”, så en 13 betyder nogenlunde det samme hver gang.
- Jobstørrelse bliver politisk: Estimér med det udførende team, og adskil “hast” fra “sværhed”.
- Alt får høj tidskritikalitet: Kræv en konkret begrundelse (deadline, tab af omsætning, kontrakt) før en høj score.
- Store initiativer får automatisk høj værdi: Del dem op i leverbare bidder, så I kan sammenligne dem fair med mindre emner.
- CoD forveksles med budget: CoD er en relativ prioriteringsscore, ikke en økonomisk prognose i kroner.
Når WSJF “fejler” i praksis, er det ofte fordi scoringerne ikke er sammenlignelige, eller fordi backloggen indeholder ting, der ikke reelt konkurrerer om samme kapacitet.
Tilpasninger: når standard WSJF ikke passer helt
Standardtilgangen summerer de tre CoD-komponenter med samme vægt. I nogle organisationer er det fornuftigt at justere, men gør det med omtanke og dokumentér hvorfor.
To typiske tilpasninger:
- Vægtning af CoD-komponenter
Hvis tidskritikalitet er markant vigtigere end alt andet (fx ved regulatoriske deadlines), kan man gange tidskritikalitet med en fast faktor. Det gør modellen mere følsom over for det, der reelt presser jer. - Opdeling i horisonter
Når I sammenligner meget forskellige typer arbejde (drift, innovation, platform, compliance), kan “kortest først” skubbe de langsigtede investeringer ud. En løsning er at lave WSJF-ranking inden for hver horisont og derefter allokere kapacitet pr. horisont.
Uanset tilpasning: hold fast i idéen om relativ scoring og gennemsigtighed. Hvis I ikke kan forklare prioriteringen i almindeligt sprog, hjælper matematikken jer ikke.
Praktisk opsætning i Jira, Sheets eller et simpelt board
I behøver ikke specialværktøjer for at komme i gang. Et regneark fungerer fint til de første runder, og mange teams ender med at bygge WSJF direkte ind i deres backlogværktøj.
En pragmatisk opsætning er:
- Felter for de tre CoD-komponenter (tal)
- Ét felt for jobstørrelse
- Ét beregnet felt eller kolonne for CoD-sum
- Ét beregnet felt eller kolonne for WSJF
Hvis jeres værktøj ikke understøtter beregnede felter, kan I stadig gøre det enkelt: gem scoringerne i backloggen og beregn WSJF i et ark, når I laver planlægning. Det vigtige er, at scoringerne bliver liggende, så I kan se historikken og justere, når ny viden dukker op.
En lille praktisk vane, der løfter kvaliteten
Når I har beregnet WSJF, så brug fem minutter på at kigge på top 5 og stille ét spørgsmål: “Hvad skulle være sandt, for at denne score giver mening?” Hvis svaret er uklart, er der et antagelsesproblem, ikke et regneproblem.
Prøv også at gen-score med faste intervaller, fx hver måned eller ved større roadmap-opdateringer. Værdi ændrer sig, deadlines flytter sig, og risiko bliver enten mindre eller større, når I lærer mere.
Når WSJF bliver en rytme, får I et fælles sprog for prioritering, der kan bruges i dialogen med både ledelse, produkt, drift og udvikling uden at samtalen ender i ren smag og behag.
— Du kan få dem tilsendt herunder! —
