MoSCoW metoden – Sådan prioritere du nemt opgaver

Indholdsfortegnelse

Nogen gange kan det sværeste i et projekt være at prioritere projektets krav. Alle projekter er nemlig underlagt 3 rammer, nemlig tid, budget og omfang. Som oftest er minimum to af disse fastsat og urokkelige fra start, og det er sjældent at man oplever et projekt med uendelig højt budget, uden en deadline, og hvor omfanget af leverancen er uendelig stor. Alle tre rammer er ofte defineret i starten af projektet, men de kan ikke alle være “urokkelige” da du som projektleder skal kunne skrue på en af de tre rammer for at kunne justere projektet ind med hvis der skulle være brug for det.

Som oftest er der to faste rammer på næsten alle projekter. Det kunne eksempelvis være tid og budget, hvor man som projektleder skal få så meget presset ind i projektet som muligt, inden for en foruddefineret dato og til en foruddefineret pris. Det kunne også være tid og omfang skal forsøge at få det fulde omfang leveret inden en given dato, men hvor budgettet er til at justere op og ned efter behov, så man ville kunne tilkøbe flere ressourcer hvis projektet skulle falde bagud i forhold til projektplanen. Det kunne også være budget og omfang hvor du skal levere et foruddefineret omfang til et foruddefineret budget, men hvor du vil kunne trække projektet ud hvis der skulle være brug for det.

Man vil selvfølgelig helst kunne overholde alle rammer, men det er ikke altid muligt. MoSCoW metoden er en prioritering metode som du skal bruge på krav og opgaver i projekter som ikke har omfanget som et af de urokkelige rammer. For med MoSCoW metoden vurdere du nemlig hvilke opgaver som man vil kunne skære fra i et givet projekt, hvis det viser sig at projektet ikke kan leveres inden for de forudsatte rammer. De rammer som oftest sættes på projekter er tid og budget, og det er derfor at MoSCoW metoden er blevet så vigtigt et værktøj for projektlederen i dag.

MoSCoW metoden

MoSCoW metoden til prioritering blev udviklet af Dai Clegg fra Oracle tilbage i 2004, og har siden den tid været en favorit blandt projektledere og systemudviklere når det kom til prioritering af opgaver. MoSCoW tvinger nemlig projektlederen og andre stakeholders til at definere hvor vigtig en opgave er for projektets succes. MoSCoW metoden får sit navn fra de første bogstaver i “Must have”, “Should have”, “Could have”, og “Won´t have”/”Would have in another relase”. Man prioriterer på den måde opgaverne ved at give dem en af disse statusser. Nedenfor kan du læse mere om disse statusser.

“Must have”

Det vil sige, projektet kan slet ikke gennemføres uden, eller det endelige produkt vil være så ubrugeligt hvis det ikke er der. Det er ofte relativt få opgaver som får betegnelsen “Must have” da det reelt set er få opgaver som er absolut “Must have”. Mange laver ofte den fejl at lave alt for mange “Must have” prioriteringer, og jeg ser mange “Must have” som i virkeligheden burde være en “Should have”. Jeg stiller tit folk det meget simple spørgsmål “Hvor vigtigt er det at vi får det udviklet i projektet?” og overraskende mange siger at det er et “Must have” fordi det bør vi have med i projektet. Lig gerne mærke til lige præcis “bør” i denne sætning. Når folk formulere det sådan, så er det næsten altid en “Should have” og ikke en “Must have”. Folk har næsten altid en uddybende grund til “Must have” opgaver, og uddyber næsten altid deres svar med “… fordi eller kan vi ikke…”.

Eksempler på “Must have” kunne være:

  • Løsningen kan ikke bruges uden denne funktion (Tage kreditkort på en webshop)
  • Læsningen kan ikke leveres uden denne funktion (Find hosting til webshop)
  • Løsningen er ikke lovligt uden de givne opgaver er løst (Få styr på GDPR)
  • Opgaven blokere udviklingen en anden opgave som er “Must have” (Købe SSL certifikat så vi kan tage kreditkort)

“Should have”

Det vil sige at det ville gøre en stor forskel at få dette implementeret i projektet. Det ville med andre ord give virksomheden eller brugeren en stor værdi hvis det blev udviklet. Løsningen ville måske endda være en ret dårlig løsning uden nogen som helst “Should have” opgaver. Men som udgangspunkt kan løsningen godt fungere nogenlunde uden alle “Should have”. Dog skal det også lige siges at det skal gå rigtig galt for at et projekt leveres kun med “Must have”, men mere om det nedenfor.

Eksempler på “Should have” kunne være:

  • Løsningen giver brugere mere værdi med denne funktion (Simpelt checkout-flow, flot produktside, nem navigation)
  • Løsningen giver virksomheden mere værdi med denne funktion (Tracking, ordrehåndterings-flow, ERP integration)

“Could have”

“Could have” er alle de ting som giver god værdi for enten virksomheden som har startet projektet, eller brugeren af det endelige produkt, men som ikke er kritiske. “Could have” kategorien er derfor ikke uvæsentlig, men den er mindre vigtig end “Must have” og “Should have”. Det er derfor heller ikke unormalt at nogle “Could have” funktionaliteter bliver sparet væk sidst i projektet hvis man er ved at løbe tør for tid eller budget.

Eksempel på “Could have” kunne være:

  • Ønskelige funktioner som ikke er vitale, men som kunne være “Nice to have” (Lead genererende popup forms)
  • Funktioner som spare virksomheden tid ved et spare på interne ressourcer (Automatisk Track&Trace, Chatbot, Lave en FAQ sektion)

“Would have in another release”

“Would have in another release” er alle de ting som kunne giver værdi, men som ikke er esensielt for projektets succes. Det er ofte her man finder funktionaliteter som man “gemmer” til fremtidige videreudviklinger på projektet, når der igen er enten budget eller tid til at kigge på det.

Eksempel på “Would have” kunne være:

  • En ønskelig funktion som ikke er en del af din Project Vision guide, men som kunne komme med hvis der var tid og budget til det.
  • Alternativt er funktionen blevet oprettet som en requirement som senere laves og leveres.

Hvilken prioritet en opgave/funktion får kommer an på hvordan opgaven/funktionen passer ind i projektets Vision Statement. Jeg kommer ikke så meget ind på hvad en vision statement er i denne artikel, men kort fortalt er det et dokument der fortæller hvad udbyttet af projektet skal være. Med MoSCoW metoden giver man så en prioritet til en opgave/funktion efter hvor vigtig den er for at nå projektets Vision Statement.

Forventningsafstemning omkring MoSCoW

Det er forskelligt fra projekt til projekt hvor meget man får med af funktioner/opgaver oprettet i projektet. Men der er typisk tre mulige scenarier som du kan forvente:

Best case: Alle “Must have”, “Should have” og “Could have” leveres i projektet.
Expected case: Alle “Must have” og “Should have” leveres i projektet, samt nogen af “Could have”.
Worst case: Kun must have leveres, samt nogen af “Should have”.

Min erfaring siger mig at det ofte en blanding mellem Expected case og Best case som du kan forvente når du har afsluttet projektet. Som oftest får man alle “Must have” og “Should have” med i projektet, samt nogen af de “Could have” opgaver som er blevet samlet sammen igennem projektet.

Sådan planlægger du dine sprints

Når du planlægger dine sprints så kan du arbejde med 60:20:20 reglen. Den går i alt sin enkelthed ud på at du i hvert sprint skal have følgende opdeling af opgaver:

  • 60% på Must have opgaver
  • 20% på Should have opgaver
  • 20% på Could have opgaver

Denne fordeling kan du bruge i starten af projektet, og så længe at projektet er on-track. Så snart projektet begynder at skride i forhold til enten tid eller budget, så bør du fokusere mere på Must have og Should have opgaverne. Der kan du enten lave et 80:20 split eller 70:30 split alt efter hvor kritisk situationen er blevet. Kun en enkelt gang har jeg oplevet at man til sidst i projektet var nød til at allokere 100% til Must have opgaver, blot for at få leveret alle Must have krav. I det projekt fik vi leveret alle “Must have”, næsten alle “Should have” og en god del af “Could have” opgaverne. Det der skete i det projekt var at projektlederen ikke havde styr på fordelingen af opgaver i starten af projektet, han allokerede løst bare opgaverne til de forskellige sprints, og vi endte faktisk med at løse en del “Could have” opgaver i starten af projektet, hvor vi burde have haft fokus på “Must have” i stedet. Jeg var kun studenter medhjælper i det projekt dengang, men kan stadig huske frustrationen over den stressende afslutning af projektet. Så prøv at følg fordelingen ovenfor så vidt muligt, så burde du være sikker på at nå i mål med “Expected case”.

MoSCoW prioriteringen kan ændre sig

MoSCoW prioriteringen ændre sig igennem projektets levetid, det vil med andre ord sige at et krav i starten af projektet sagtens kunne være et “Could have”, men senere i projektet blive estimeret om igen til at være en “Should have”. Så MoSCoW prioriteringen skal ses som en dynamisk process der foregår hvert sprint, og som derfor løbende bliver vedligeholdt. Jeg har eksempelvis også prøvet at en “Would have” pludselig blev til en “Must have” da det viste sig at den funktion var krævet for at en af vores “Must have” kunne laves, den blev på den måde indirekte en “Must have” selv, da vi ellers ikke kunne levere den “Must have”.

Hvordan jeg bruger MoSCoW i Trello

Jeg bruger som udgangspunkt altid Trello til mine projekter. Det jeg gør normalt er så at bruge labels i Trello til at prioritere opgaverne efter MoSCoW metoden. Jeg opretter med andre ord bare 4 labels i rød, orange, gul og grøn, og opkalder dem derefter blot “Must have”, “Should have”, “Could have” og “Would have in another release”. Det giver mig en meget visuel metode til at se hvilke opgaver der har en høj prioritet, og hvilke der kan vente til senere.

Mark Guldbrandsen

Mark Guldbrandsen

Erfaren projektleder med speciale i digitale projekter. Rig på erfaring med udvikling og udrulning af hjemmesider, webshops, CRM systemer og meget andet.

Skriv en kommentar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *

Værktøjer som jeg arbejder med til dagligt: