MoSCoW¶
De MoSCoW-methode is een prioriteringstechniek die je kan gebruiken bij softwareontwikkeling om samen met belanghebbenden (‘stakeholders’) de prioriteit van vereisten (‘requirements’) te bepalen.
De term zelf is een acroniem: M - Must have, S - Should have, C - Could have, W - Won’t have (De O’s hebben dus geen betekenis en dienen alleen om er een woord van te maken). De Engelse betekenis van de categorieën geeft klanten een beter inzicht in de impact van het stellen van een prioriteit, vergeleken met alternatieven als Hoog, Gemiddeld en Laag.
MoSCoW wordt vaak gebruikt in combinatie met timeboxing (bij Scrum zijn dat sprints), waarbij een deadline wordt vastgesteld zodat de focus op de belangrijkste requirements moet liggen. Alle requirements zijn belangrijk, maar om in een vroeg stadium de grootste waarde te realiseren zullen ontwikkelaars in eerste instantie proberen aan alle Must have-, Should have- en Could have-requirements te voldoen, maar de Should- en Could-requirements zullen als eerste worden verwijderd als de leveringstermijn bedreigd lijkt.
De categorieën worden meestal opgevat als:
Must-have: Deze requirements zijn van cruciaal belang om de huidige sprint tot een succes te maken. Als zelfs maar één Must-have-vereiste niet is opgenomen, moet de oplevering als een mislukking worden beschouwd.
Should-have: Deze requirements zijn belangrijk, maar niet noodzakelijk. Hoewel de Should-have-requirements net zo belangrijk kunnen zijn als de Must-have-requirements, zijn ze vaak niet zo tijdsgebonden of kan er een andere manier zijn om aan deze requirement te voldoen, zodat deze kan worden uitgesteld naar een toekomstige sprint.
Could have: Deze requirements zijn wenselijk maar niet noodzakelijk en kunnen de gebruikerservaring of klanttevredenheid verbeteren tegen weinig ontwikkelingskosten. Deze zullen doorgaans worden opgenomen als de tijd en de middelen dit toelaten.
Won’t have: Dit is een van de belangrijkste onderdelen van de analyse. Deze requirements zijn door de stakeholders beoordeeld als alle functies en punten die specifiek niet in het product zullen worden opgenomen. Dit gedeelte is van cruciaal belang omdat het de reikwijdte van het project aanzienlijk verkleint en helpt bij het definiëren van de grenzen die moeten worden gevolgd om een succesvol project te realiseren. Het kan bij voorbeeld helpen bij het realiseren van een zeer specialistisch product.