Skip to content

Heb jij als teamlid, product owner of klant wel eens meegemaakt dat je team aan het einde van een sprint nog niet klaar was met alle geplande items? Of dat halverwege bleek dat bepaalde onderdelen veel belangrijker waren dan gedacht?
Grote kans dat je baat hebt bij de MoSCoW methode: een slimme manier om prioriteiten te stellen waarbij je altijd een buffer hebt voor tegenvallers. Je garandeert de oplevering van de belangrijkste dingen én houdt ruimte om te leren en aan te passen aan veranderende omstandigheden.

Wat betekent MoSCoW?

MoSCoW verdeelt alle te ontwikkelen product-functies in vier groepen:

 

Wie bepaalt de prioriteiten?

De klant bepaalt welke functies van het product de meeste waarde hebben. Wat past het beste bij zijn doelstelling? Deze keuze beïnvloedt direct je MoSCoW indeling.

Bij software bijvoorbeeld: bouw je een app voor snelle communicatie of voor veilige opslag? In elk van deze gevallen krijgen functies een andere prioriteit. Bij de bouw van een een serre: meer woonruimte nodig of vroeg in het seizoen zonnen? Andere doelen, andere Must Haves.

MoSCoW verandert per moment

Hier wordt het interessant: als je stapsgewijs ontwikkelt, kunnen je prioriteiten per moment anders zijn.

Voorbeeld: Je bouwt een serre aan je huis in drie fasen van elk drie weken.

Voor de hele serre zijn muren “Must Have”. Maar in sprint 1? Dan staat de fundering centraal en zijn muren “Won’t Have This Time”.

Dit betekent dat je drie verschillende prioriteitenlijstjes kunt hebben:

  • Voor het hele project
  • Voor de huidige fase
  • Voor de huidige sprint

 

Tot het moment dat je echt begint met bouwen, kun je prioriteiten nog aanpassen. Blijkt het handiger om eerst de buitenmuur te plaatsen en dan het dak? Geen probleem, verschuif de prioriteiten.

Prioriteit ≠ volgorde

Let op: MoSCoW zegt hoe belangrijk iets is op basis van waarde, niet altijd in welke volgorde je het moet doen.

Voorbeeld serre:

  • Muren stucen = Must Have
  • Gordijnen ophangen = Must Have (privacy!)
  • Muren schilderen = Should Have (mooi, maar niet essentieel)

Maar je schildert natuurlijk liever eerst de muren voordat je gordijnen ophangt. Anders moet je de gordijnen er weer afhalen.

De vraag wordt dan: “Hebben we zeker tijd om zowel te schilderen als om de gordijnen op te hangen?” Ja? Doe beide in logische volgorde. Nee? Skip het schilderen, doe eerst alleen de gordijnen.

De 60-20-20 vuistregel

Voor effectieve prioritering: houd maximaal 60% Must Haves, ongeveer 20% Could Haves en de rest is Should Haves.

Waarom? Met minder dan 60% Must Haves kan je team ze echt garanderen. Met 20% Could Haves heb je genoeg buffer voor als het misgaat.

Let op: dit zijn geen heilige getallen! Risicovolle projecten (nieuwe technologie, nieuw team) nemen beter minder Must Haves. Een ervaren team kan iets meer aan.

Verwachtingen helder houden

Met deze werkwijze kun je garanderen dat alle Must Haves worden opgeleverd. Je klant mag ook verwachten dat de Should Haves lukken. En als alles meezit, ook nog wat Could Haves.

Waarom niet alles garanderen? Omdat planningen gebaseerd zijn op schattingen en de wereld verandert terwijl je ontwikkelt. Functies kunnen overbodig worden of juist veel belangrijker. Je leert onderweg bij – als team én als klant.

Houd bij hoeveel Should Haves en Could Haves je daadwerkelijk oplevert. Gaat het goed? Mooi! Gaat het slecht? Dan heb je een vroeg waarschuwingssysteem.

Zo gebruik je MoSCoW niet alleen om te prioriteren, maar ook om slimmer te leren en aan te passen.

Back To Top