Slik gjør du enklere prioriteringer ved bruk av MoSCoW-metoden

Smidige metoder

7 min. lesning

Noe av det vanskeligste for ledere og prosjektledere er å prioritere. Dette gjelder både for linjeoppgaver, i smidige leveranser og i prosjekter. Det vil alltid være mange ønsker og meninger fra ulike hold, og det gjelder å holde hodet kaldt og få et overblikk over hva som er viktigst for virksomheten, prosjektet eller produktet, kunden og sluttbrukeren.

Virksomheter som tar hensyn til kundenes krav, ønsker og prioriteringer i et prosjekt eller i utviklingen av et produkt, er betydelig bedre og mer lønnsomme enn de som ikke gjør det. De som også forstår prioriteringene sine og evner å sette dem i riktig rekkefølge etter hvor viktige de er for prosjektet, er enda bedre. Et godt hjelpemiddel for å gjøre prioriteringer er metoden MoSCoW.

I dette blogginnlegget skal vi se nærmere på hvordan man kan bruke MoSCoW-metoden for å prioritere mellom ulike krav og oppgaver i et prosjekt.

Hva er MoSCoW?

MoSCoW er en prioriteringsmetode som ofte blir brukt innenfor ledelse, prosjektledelse, virksomhetsanalyse og spesielt i smidige team. Metoden gjør det enklere å skape en felles forståelse og bruke tilgjengelige ressurser på det som faktisk er viktigst.

MoSCoW ble oppfunnet av Oracle-ansatt Dai Clegg i 1994. Selv om metoden ofte blir brukt for å prioritere mellom ulike krav fra kunder i prosjekter så er den like godt egnet til oppgaver som går inn under den daglige driften av en virksomhet eller i team som driver med kontinuerlig utvikling.

MoSCoW-metoden brukes ofte i forbindelse med et DSDM-prosjekt, som står for Dynamic System Development Method. Et prinsipp i DSDM som brukes i forbindelse med MoSCoW er Timeboxing. Det innebærer at man deler opp prosjektet i trinn, hvor hver del får et eget budsjett og en tidsramme. Innenfor hver fase må det prioriteres hva som skal løses. Slik kan også prioritering foregå fasevis eller man kan avgjøre hvorvidt et krav skal tas helt ut av prosjektet.


Last ned gratis malpakke for AgileSHIFT


MoSCoW-analyse er en effektiv teknikk når man har behov for å se sammenhengen mellom krav og prioriteringer. Den inneholder tre tydelige prioritetsnivåer, men dekker også kravene som til slutt ikke vil bli inkludert i den nåværende leveransen.

MoSCoW er et akronym for fire prioriterings-kategorier og står for:

  • Must have - (må ha)
  • Should have - (børe ha)
  • Could have - (kunne ha)
  • Won’t have - (vil ikke ha)

På norsk brukes gjerne akronymet MåSKVa. MoSCoW fungerer godt fordi modellen skaper en felles forståelse på hvorfor de ulike kravene må inkluderes eller ekskluderes og prioriteringen av rekkefølgen av disse blir tydelig for alle i teamet.

M – Must have (må ha)

Must have-kriteriet representer de oppgavene eller kravene som prosjektet ikke kan leveres uten. Dette kalles gjerne Minimum Usable Subset og bør ikke bestå av mer enn 60 prosent av det totale omfanget. En «must have»-oppgave skal være så viktig at dersom man fjerner en slik oppgave vil det være meningsløst å levere prosjektet eller produktet. For eksempel hvis du skal lage en ny webside til en kunde så kan du ikke levere det uten en navigasjon for websiden. En grei måte å få sjekket kriterier inn og ut av Must have-kategorien er å stille seg spørsmålet; Hvis denne oppgaven eller kravet ikke kommer med – kommer vi oss videre da? Hvis svaret er nei, så er oppgavene en Must have. Hvis man kommer videre uten denne oppgaven eller kravet, da har man kanskje funnet en Should have eller Could have.

S – Should have (bør ha)

Det neste kriteriet, Should have, representer det som er viktig, men ikke essensielt. Å ekskludere oppgaver eller krav her er ikke avgjørende for prosjektresultatet eller produktets levedyktighet, men kan kreve noe omarbeid som for eksempel å styre forventinger eller enn manuell løsning. Dette kan være en midlertidig løsning, men Should have-oppgavene kan bli utviklet senere. Om prosjektet har tilgjengelig ressurser, og det ikke går i veien for et Must have-krav som finnes, så burde disse kravene leveres eller inngå i omfanget som prioriteres.

C – Could have (kunne ha)

Could have er et krav som er ønskelig, men mindre viktig og som har en mindre innvirkning på prosjektet eller sluttproduktet. En måte å differensiere mellom disse er å se på hvilken verdi det tilfører sluttproduktet eller gevinstrealisering av prosjektet. Det kan også være lurt å prioritere ut fra størrelsen på gruppen som denne oppgaven eller denne prioriteringen berører. Jo større innvirkning det har, jo mer sannsynlig er det at kravet burde være en Should have. I et beste fall vil man være i stand til å levere alt som ligger under Could haves. Hvis det dukker opp problemer eller man står i fare for å ikke nå en tidsfrist så kan en eller flere av oppgavene som i utgangspunktet er definert som en Could have bli droppet for å nå tidsfristen. Oppgaver som ligger under dette kriteriet bør ikke representere mer enn 20 prosent av det totale omfanget.

W – Won’t have (vil ikke ha)

I et hvilket som helst prosjekt, vil et team være enige om at det er visse oppgaver eller krav som det ikke er mulig eller nødvendig å levere. Dette er Won’t have-krav som ikke vil bli inkludert akkurat nå, men som man kanskje ønsker å implementere på et senere tidspunkt.

Disse bør loggføres i en Prioritized Requriements List (PRL) slik at man får en god oversikt over omfanget av prosjektet og at det blir enklere å eventuelt ta inn oppgaven eller kravet senere. Dette gjør det også lettere å styre forventinger til hvilke krav som vil være med når prosjektet eller produktet er ferdig.

Ved å ekskludere det som ikke kan implementeres akkurat nå, blir det tydeligere hvilke oppgaver og krav fokuset bør være på.

Gjør det enklere å prioritere rett

MoSCoW er en enkel og effektiv måte å prioritere arbeid på. Ved å fokusere på de viktigste oppgavene først så vil hovedkomponentene av prosjektet bli ferdig raskere, og man kan eventuelt legge til det som er mindre viktig senere. Metoden bidrar til å sikre en felles forståelse for prosjektet slik at alle vet hva som jobbes med, og hvorfor akkurat den oppgaven eller det kravet ble prioritert først.

Å bruke MoSCoW betyr også at både kunde- og prosjektgruppen kan bestemme at noen oppgaver eller krav ikke bør være med i prosjektet i det hele tatt. Det bidrar til å man får luket ut unødvendige deler tidlig og at man holder ting smidig og enkelt. MoSCoW er en av aspektene ved smidige leveranser som hjelper teamet med å minimere bortkastet tid, krefter, ressurser og penger.

I AgileSHIFT finnes det en egen mal for prioritering som er kompatibel med både MoSCoW-metoden og enkel numerisk prioritering. Du kan lese mer om maler og agendaer for smidige sprinter med AgileSHIFT her.

Get free brochure about the Executive MBA


Christine jobber som Product Marketing og Growth Manager i Metier og har tidligere jobbet som journalist i USA. Hun er ansvarlig for at vi produserer nyttig informasjon og fagstoff relatert til prosjektledelse, smidig og digitalisering. Christine har studert media og kommunikasjon på University of South Florida, er sertifisert i PRINCE2 Foundation og ScrumMaster og har en diplomgrad i prosjektledelse fra SKEMA Business School.


Likte du dette blogginnlegget? Da tror vi at disse også passer for deg

7 tips til å lykkes med bruk av flere rammeverk på en gang

Innen IT er det nå mange nyttige rammeverk som dekker hvordan vi kan organisere, forvalte, utvikle eller omstille vår virksomhet. Både teknologi, prosesser og organisasjon er omfattet. Hver standard har et verdifullt innhold, men det kan være utfordrende å se sammenhenger og grenseflater mellom dem. Særlig hvis du leder prosjekter eller omstillinger der for eksempel PRINCE2, MSP, MOP, PROSCI, TOGAF, ISO27001/2, IT4IT, ITIL4, SAFe, SCRUM, ITPP (for å nevne noen) eller flere er aktuelle å ta i bruk. Her gir vi deg 7 tips til hvordan du kan lede for å bruke rammeverkene på beste måte.

Hvorfor ønsker vi hyppige leveranser i smidige prosjekter?

Når vi gjennomfører prosjekter eller initiativer etter smidige metoder, ønsker vi å levere verdi underveis. Dette gjør man gjennom å levere gevinster gjennom prosjektets livssyklus i form av hyppige leveranser. Hyppige leveranser underveis er en av hovedhensiktene med å kjøre et prosjekt etter smidige prinsipper. I stedet for tradisjonelt å tenke på et prosjekt som et langt forløp som skal levere et sluttprodukt bør prosjektet planlegges som en serie av leveranser. I dette blogginnlegget gir vi deg syv gode grunner til å fokusere på hyppige leveranser.

Hva er Large Scale Scrum (LeSS)?

For dagens virksomheter er evnen til å tilpasse seg endringer raskt og effektivt avgjørende for suksess. Mens Scrum har nesten blitt en uunngåelig grunnmetode i digitaliseringsinitiativer, står store organisasjoner overfor utfordringer når de forsøker å skalere smidigheten til komplekse programmer. Large Scale Scrum (LeSS) har vokst frem som en prominent løsning for å møte disse utfordringene.