Introduktion til MoSCoW
I dette indlæg skal vi kigge lidt på MoSCoW. Herunder hvorfor man er nød til at prioritere opgaver i et projekt, og hvorfor MoSCoW er den ideelle metode at bruge til dette.
Hvorfor skal man prioritere opgaver?
Alle projekter er underlagt 3 rammer, nemlig tid, budget og omfang. Som oftest er minimum to af disse fastsat, og urokkelige fra start. Men det er sjældent, at man oplever et projekt med uendelig højt budget, uden en deadline, og hvor omfanget af leverancen er uendelig stort.
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å ville man 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.
Hvad er MoSCoW metoden?
MoSCoW metoden er et projektstyringsværktøj som hjælper dig med prioritering af projektets opgaver, det er særligt nyttigt til risikominimering i projektet. Fordi, nogle gange kan det sværeste i et projekt være at prioritere projektets krav, når projektet ikke længere kører som planlagt i forhold til enten budget eller deadlines.
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 vurderer 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.
Nedenfor kan du se en video omkring MoSCoW, med en let forståelig forklaring baseret på en fiktiv case.
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.
Hvorfor er MoSCoW så populært?
MoSCoW tvinger 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 de forskellige statusser, samt nogle eksempler til hvert af dem.
MoSCoW metoden forklaret
“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. Læg gerne mærke til lige præcis “bør” i denne sætning.
Når folk formulerer 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 ellers 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 (Finde hosting til webshop)
- Løsningen er ikke lovligt, uden de givne opgaver er løst (Få styr på GDPR)
- Opgaven blokerer 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 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 sparer virksomheden tid ved at 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 give værdi, men som ikke er essentielt 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 projektets målsætninger, men som kunne komme med, hvis der var tid og budget til det.
- Alternativt er funktionen blevet oprettet som en opgave som senere laves og leveres.
Hvilken prioritet en opgave/funktion har, kommer an på, hvordan opgaven/funktionen passer ind i projektets målsætninger. Jeg kommer ikke så meget ind på, hvad projektets målsætninger 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 målsætninger.
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 nogle 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 50:30:20 reglen. Den går i alt sin enkelthed ud på, at du i hvert sprint skal have følgende opdeling af opgaver:
- 50% på Must have opgaver
- 30% 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.
Hvad nu hvis projektet bagud?
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 (80% Must have og 20 Should have) eller et 70:30 split alt (70% Must have og 30% Should have) alt efter, hvor kritisk situationen er blevet.
Kun en enkelt gang har jeg oplevet, at man til sidst i projektet var nødt 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 han burde have haft fokus på “Must have” i stedet.
Jeg var kun studentermedhjælper i det projekt dengang, men kan stadig huske frustrationen over den stressende afslutning af projektet. Så prøv at følge fordelingen ovenfor så vidt muligt, så burde du være sikker på at nå i mål med “Expected case”.
Kan MoSCoW prioriteringen kan ændre sig?
MoSCoW prioriteringen ændrer 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 bliver estimeret om igen til at være en “Should have”. Så MoSCoW prioriteringen skal ses som en dynamisk proces, der foregår hver 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”.
Opsummering
MoSCoW metoden er et projektstyringsværktøj, som hjælper dig med prioritering af projektets opgaver, det er særligt nyttigt til risikominimering i projektet. Fordi nogle gange kan det sværeste i et projekt være at prioritere projektets krav, når projektet ikke længere kører som planlagt i forhold til enten budget eller deadlines.
MoSCoW metoden er rigtig god at have i din værktøjskasse. Det er desværre ret ofte at den ender med at være handy, primært hvis du driver agile projekter. Alle projekter er jo underlagt projektets trekant (Tid – Budget – Omfang) og det er nok usandsynligt at alle disse tre vil være urokkelige
Med MoSCoW metoden har du mulighed for at sikre dig, at de vigtigste opgaver bliver en del af det endelige slutprodukt.
