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

Smidige metoder Nivå - Team

6 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 Inbound Marketing Manager i Metier OEC og har tidligere jobbet som journalist i USA. Hun er ansvarlig for at vi produserer nyttig informasjon og fagstoff relatert til prosjektledelse for å bistå alle som jobber i og med prosjekter. Christine har studert media og kommunikasjon på University of South Florida, er sertifisert i PRINCE2 Foundation og har en diplomgrad i prosjektledelse fra SKEMA Business School.


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

10 gode podcaster om smidige metoder

Det skjer mye i det smidige miljøet og det kan tidvis være vanskelig å henge med. Det å høre på podcaster er en genial måte å holde seg oppdatert på. Det er utrolig hvor mye man kan tilegne seg uten den store innsatsen, bare ved å ha en podcast på øret. Her kommer vår 10-på-topp-liste over podcaster som vi kan anbefale på det varmeste. Dette er ikke i prioritert rekkefølge, men enkelt og greit gode podcaster som det er verdt å sjekke ut.

Hva tar vi med oss fra Oslo Business Forum 2022?

Vi er proppfulle av nye tanker og innsikt etter to dager på Oslo Business Forum 2022. En rekke verdenskjente foredragsholdere har alle gitt sin fortolkning av hva Future Focused Leadership er. Her er hovedpunktene fra noen av dem, og til sist noen refleksjoner vi gjør oss om det vi hørte – basert på vår kontekst i Norge.

Planning poker – også for de uten pokerfjes

Smidige prosjekter byr på masse spenning og dynamikk – til og med i form av kortspill. Agile team har derfor innsett at de ved siden av å skrive kode også kan more seg på jobb med å spille en form for poker. Poker har en lang og noe lyssky historie. Men i den smidige prosjektverden har dette kortspillet et helt annet formål enn å vinne motspillerens poker-chips. I et smidig perspektiv brukes poker til planlegging av oppgaver som gjenstår å fullføre. Så her kan man ikke forvente en royal flush, og det kan spilles uten å bruke solbriller – for de som ikke har pokerfjes.