Articles

MoSCoW-methode

Posted on

Alle vereisten zijn belangrijk, maar ze krijgen prioriteit om de grootste en meest directe zakelijke voordelen vroeg te leveren. Ontwikkelaars zullen in eerste instantie proberen alle Must have-, Should have- en Could have-vereisten op te leveren, maar de Should en Could-vereisten zullen als eerste worden geschrapt als het tijdschema voor oplevering in gevaar komt.

De duidelijke Engelse betekenis van de prioriteringscategorieën is waardevol om klanten beter te laten begrijpen wat de impact is van het stellen van een prioriteit, in vergelijking met alternatieven als Hoog, Gemiddeld en Laag.

De categorieën worden typisch opgevat als:

Must have Vereisten die als Must have worden bestempeld, zijn van cruciaal belang voor de huidige oplevertermijn, wil deze een succes worden. Als ook maar één Must have vereiste niet is opgenomen, moet de oplevering van het project als mislukt worden beschouwd (let op: vereisten kunnen worden gedegradeerd van Must have, met instemming van alle relevante belanghebbenden; bijvoorbeeld wanneer nieuwe vereisten belangrijker worden geacht). MUST kan ook worden beschouwd als een acroniem voor de Minimaal Bruikbare Subset. Should have Requirements gelabeld als Should have zijn belangrijk maar niet noodzakelijk voor oplevering in de huidige opleveringstermijn. Hoewel Should have requirements even belangrijk kunnen zijn als Must have, zijn ze vaak niet zo tijdkritisch of er kan een andere manier zijn om aan de requirement te voldoen zodat deze kan worden uitgesteld tot een toekomstige opleveringstermijn. Could have Requirements gelabeld als Could have zijn wenselijk maar niet noodzakelijk en zouden de gebruikerservaring of klantentevredenheid kunnen verbeteren voor een beetje ontwikkelingskost. Deze zullen typisch worden opgenomen als de tijd en middelen het toelaten. Won’t have (this time) Requirements gelabeld als Won’t have, zijn door de stakeholders aangemerkt als de minst kritieke, minst renderende items, of niet geschikt op dat moment. Als gevolg daarvan worden Won’t have requirements niet ingepland in de planning voor de volgende opleveringstermijn. Won’t have requirements worden ofwel geschrapt ofwel heroverwogen voor opname in een latere timebox. (Opmerking: soms wordt de term Would like to have gebruikt; dat gebruik is echter onjuist, aangezien deze laatste prioriteit duidelijk aangeeft dat iets buiten de scope van levering valt). (De BCS in editie 3 & 4 van het Business Analysis Book beschrijven ‘W’ als ‘Wil hebben, maar deze keer niet’)

VariantenEdit

Soms wordt W gebruikt om Wens (of Zou) te betekenen, d.w.z. nog steeds mogelijk, maar onwaarschijnlijk om te worden opgenomen (en minder waarschijnlijk dan Zou kunnen). Dit wordt dan onderscheiden van X voor Excluded voor items die expliciet niet zijn opgenomen.

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *