MoSCoW methode geeft je een prioriteitenlijst

De MoSCoW-methode is een wijze van prioriteiten stellen die veel gebruikt wordt in de IT en dan met name de ontwikkeling van software en projecten. Waarom? Vaak wordt er in development veel gebruik gemaakt van Agile/Scrum. Dit is een flexibele en lichtvoetige manier van ontwikkelen. In het bepalen van je startpunt en de minimale vereisten past de MoSCoW methodiek perfect. Je prioriteert namelijk de features , gaat daarmee van eisen naar wensen en eindigt uiteindelijk bij de "ooit nog".

En waarom we MoSCoW dan zo raar schrijven? Omdat de letters staan voor een afkorting.

• M - must haves: deze eisen (requirements) moeten in het eindresultaat terugkomen, zonder deze eisen is het product niet bruikbaar;

• S - should haves: deze eisen zijn zeer gewenst, maar zonder is het product wel bruikbaar;

• C - could haves: deze eisen zullen alleen aan bod komen als er tijd genoeg is;

• W - won't haves: deze eisen zullen in dit project niet aan bod komen maar kunnen in de toekomst, bij een vervolgproject, interessant zijn.

Zoals je ziet hebben de kleine letters 'o' in de afkorting geen betekenis, maar maken de afkorting makkelijker te onthouden. In de eerste projectfase is de M dus heilig. En richt je je op de S. Daarmee ga je gelijk door naar wat ze noemen in de development-wereld een MLP (een minimum lovable product) i.p.v. een MVP (een minimum viable) product.

Mag ik je daarmee ook waarschuwen? In het eerste deel van dit artikel heb ik best veel vaktermen voorbij laten komen. Dat is ook een beetje IT-eigen. En dat is niet erg, maar zorg ervoor dat je bij de start van een opdracht duidelijk hebt wat de verwachtingen zijn en dus dat je niet vastloopt op allerlei IT-mambo jambo waarbij eenieder een ander beeld heeft.

De MoSCoW methodiek kan je daarin helpen.

MoSCoW methode als eisenpakket

Bij DAAT gebruiken we de MoSCoW methode bij de start. Je bepaalt dan namelijk je eisenpakket. Dit kan in een enkele sessie of in een designsprint.

Bij het opstellen van de eisen moet zoveel mogelijk rekening gehouden worden met wat jullie belangrijk vinden. Met elkaar brainstormen, nadenken en het scherp krijgen van de echte eisen, kun je uiteindelijk doorgaan naar hetgeen ze binnen development noemen "user stories". Dit zijn de uitgeschreven "wat heb ik eraan en kan ik ermee".

Een voorbeeld: Als Billie Eilish wil ik dat het verslag op een eenvoudige en efficiënte manier ingevoerd kan worden naar digitale vorm zodat het weinig tijd kost en kans op fouten voorkomt .

Alle eisen worden op volgorde (prioriteit) gelegd. Het belangrijkste daarbij is dat de eisen toegevoegde waarde voor het bedrijf gaan opleveren. Daarmee start je met een fundament en bouwt daarna uit.

Dit doe je dus door op te delen in de vier eerder genoemde categorieën.

Je begint met het minimale eisenpakket dat vooraf gesteld wordt en waaraan het eindresultaat moet voldoen. Zonder deze eis, faalt het project en is het product niet meer bruikbaar. Het is vereist voor een werkbaar product en er is geen alternatief.

MUST is dus in deze context dus echt moeten.

Daarna loop je door naar aanvullende en zeer gewenste eisen, die wel een hoge prioriteit hebben, maar geen vereiste zijn voor een bruikbaar eindproduct. Zonder dat deze eisen worden ingewilligd is het product evengoed bruikbaar en met het voldoen aan de eisen krijgt het product alleen maar meerwaarde. Afhankelijk van de tijd kan er altijd later nog aandacht aan deze eisen worden gesteld.

Als er tijd voor is kunnen de derde categorie aan eisen altijd nog aan bod komen. Zo niet, dan is het geen probleem en heeft het geen nadelig gevolgen voor het eindresultaat. De could-haves hebben minder prioriteit dan de should-haves. De optie wordt alleen meegenomen als er echt ruim tijd voor is om het te realiseren. Het wordt ook wel ‘nice to have’ genoemd en het is eerder een wens dan een harde eis.

Tja en dan de categorie die onder dagdromen valt. Het gaat hier om toekomstwensen die vaak niet mogelijk zijn of heel veel tijd kosten om te realiseren. Is realisatie mogelijk dan zal er veel tijd (en geld) geïnvesteerd moeten worden en is er sprake van een would-have. Vaak worden would-haves in een vervolgtraject meegenomen.

Duidelijkheid boven alles

Als de MosCoW methode goed wordt toegepast en gehandhaafd, dan ontstaat er een overzichtelijke manier om een project te leiden. Bij de start is er al veel duidelijk en dat is nodig in een ontwikkel-fase waarin er nog veel kan veranderen. Dan is het gewoon handig om de dingen die je wel kunt afspreken al duidelijk te hebben. Dat geeft rust en duidelijkheid bij de bouw en in de (nog op te bouwen) relatie.

Voor iedere deelnemer aan het project is het duidelijk wat als eerste gedaan moet worden, binnen welke termijn en waarom. Met het toekennen van prioriteiten aan eisen is een project hanteerbaar en wordt er sneller naar de deadline toegewerkt.

Door de minder belangrijke eisen voorlopig achterwege te laten is de ontwikkeling en ondersteuning van een project ook eenvoudiger. Door de focus op de sleutelvoorwaarden te leggen, ontstaat een goed product dat aan minimale eisen voldoet.

To MosCoW or not to MosCoW...that's the question.