Wat is MoSCow techniek?
De MoSCoW-methode is een prioriteringstechniek die wordt gebruikt in management, bedrijfsanalyse, projectmanagement en softwareontwikkeling om met belanghebbenden tot overeenstemming te komen over het belang dat zij hechten aan de oplevering van elke requirement; het is ook bekend als MoSCoW-prioritering of MoSCoW-analyse. De MoSCow prioriteringstechniek speelt een sleutelrol in Agile Projectmanagement. In een Agile project is het van vitaal belang om het belang van verschillende dingen te begrijpen. Dit komt omdat tijd een vaste resource is, dus prioritering wordt toegepast op requirements, taken, producten, user cases, etc. Wees zeer voorzichtig, dit is geen Agile techniek (omvat Scrum, Kanban, XP enzovoort), maar deze techniek wordt veel gebruikt in Agile. Er zijn enkele vragen in bijna alle certificeringen met betrekking tot MoSCoW techniek.
De term MoSCoW zelf is een acroniem dat is afgeleid van de eerste letter van elk van de vier prioriteringscategorieën (Must have, Should have, Could have, en Won’t have), met de tussenliggende O’s toegevoegd om het woord uitspreekbaar te maken. Hoewel de O’s meestal in kleine letters staan om aan te geven dat ze nergens voor staan, wordt ook wel de hoofdletter MOSCOW gebruikt.
Prioritering van MoSCoW-eisen
Alle eisen zijn belangrijk, maar ze worden geprioriteerd om in een vroeg stadium de grootste en meest directe zakelijke voordelen op te leveren. Ontwikkelaars zullen in eerste instantie proberen om alle Must have, Should have en Could have requirements op te leveren, maar de Should en Could requirements zullen als eerste worden verwijderd als het tijdschema voor oplevering in gevaar komt.
Must Have
Deze bieden de Minimum Usable Subset (MUS) van requirements die het project garandeert op te leveren. Dit kan worden gedefinieerd met behulp van een aantal van de volgende:
Kan niet op streefdatum opleveren zonder dit
Geen zin om op streefdatum op te leveren zonder dit; als het niet zou worden opgeleverd, zou het geen zin hebben om de oplossing op de beoogde datum in te zetten
Niet legaal zonder dit
Onveilig zonder dit
Kan de Business Case niet opleveren zonder dit
Stel de vraag: “wat gebeurt er als niet aan deze eis wordt voldaan?” Als het antwoord is “annuleer het project – het heeft geen zin om een oplossing te implementeren die niet aan deze eis voldoet”, dan is het een Must Have eis. Als er een manier is om het te omzeilen, zelfs als het een handmatige workaround is, dan zal het een Should Have of een Could Have requirement zijn. Downgraden van een eis tot een Should Have of Could Have betekent niet dat hij niet zal worden geleverd, alleen dat levering niet gegarandeerd is.
Should Have
Belangrijk maar niet van vitaal belang
Mag pijnlijk zijn om weg te laten, maar de oplossing is nog steeds levensvatbaar
Mag een of andere workaround nodig hebben, b.v. management van verwachtingen, een of andere inefficiëntie, een bestaande oplossing, papierwerk, enz.
Een Should Have kan worden onderscheiden van een Could Have door te kijken naar de mate van pijn die wordt veroorzaakt als er niet aan wordt voldaan, in termen van zakelijke waarde of het aantal mensen dat erdoor wordt getroffen.
Kunnen hebben
gewenst of wenselijk, maar minder belangrijk
Minder impact als het achterwege blijft (vergeleken met een Should Have)
Won’t Have this time
Een voordeel van de MoSCoW-methode is dat het verschillende initiatieven in de categorie “won’t-not-have” plaatst. Dit helpt bij het managen van verwachtingen over wat niet zal worden opgenomen in een specifieke release (of ander tijdsbestek waarvoor je prioriteiten stelt).
Het plaatsen van initiatieven in de categorie “zullen we niet hebben” is een manier om scope creep te helpen voorkomen. Als initiatieven in deze categorie staan, weet het team dat ze geen prioriteit hebben voor dit specifieke tijdsbestek. Sommige initiatieven in de “niet doen”-groep zullen in de toekomst prioriteit krijgen, terwijl andere waarschijnlijk helemaal niet zullen gebeuren. Sommige teams besluiten daartussen onderscheid te maken door binnen deze groep een subcategorie te creëren.
Samenvattend
MoSCoW (Must Have, Should Have, Could Have, Won’t Have this time) wordt vooral gebruikt om requirements te prioriteren, hoewel de techniek ook op veel andere gebieden nuttig is. Atern adviseert niet meer dan 60% inspanning voor Must Haves voor een project, met 40% Shoulds en Coulds. Alles hoger dan 60% vormt een risico voor het succes en de voorspelbaarheid van het project, tenzij de omgeving goed wordt begrepen, het team is samengesteld en de externe risico’s minimaal zijn.