I often see MoSCoW being used to prioritise product development work, but for anything mildly complex (almost anything, really), and especially any product  with more than one customer, it isn’t appropriate. Here’s why. What is MoSCoW? – isn’t appropriate because: MoSCoW - Must Have, Should Have, Could Have, Won’t Have It . conveys a level of certainty that doesn’t exist in reality , it’s either must have or you don’t do it. But reality is far more nuanced, there are far more shades of grey in choosing what to do next and multiple factors that should be considered. In practice it takes a binary view of the world . The words themselves are useless or, at best, problematic It about priorities or solutions. provides limited useful information to enable robust discussions You’re much better off with one of the frameworks that explicitly communicates certainty/confidence, takes a non-binary view and provides additional information like . Kano or RICE Still not convinced? Let me elaborate on each point above. #1 It conveys a level of certainty that doesn’t exist in reality The problem starts with the first keyword for Must Have. Define . When pressed most people respond with “the customers said they have it” which is a problematic statement. “Must” must must First, itself has no relativity built in. It’s binary but the reality is different. It’s rare that 100% of customers have unanimously and unambiguously agreed that they Must Have a certain feature. In reality they’ve given some hints, maybe even some observed behavioural data, about what you hypothesise might be their more important needs but even then you will get mixed signals. must You will get differences between customers in the nature of the need; differences between value of the item to a customer, differences in the value of the items to the business, differences in the attractiveness of your proposed solution and differences in the number of customers it applies to. Second, the word itself conveys a level of confidence that is misleading and even dangerous. You cannot say with complete confidence, especially in a new product or feature, what is a Must Have. You have some assumptions about what is more valuable, you can even make these assumptions with high confidence. But MoSCoW as a framework for product prioritisation provides no metadata around what that confidence level is or how you arrived at it. must If I ask my 5 year old which toy she wants to take to the farm then they’re all “must haves”. If I tell her she can only pick two, then suddenly she prioritises. If a feature or need is taken on it’s own then people will say “I must have” but when confronted with choices they tell a different story. Before you jump to make the argument “that’s what Should Have and Could Have are for”, let me jump in and point out that within Must Have you still need to prioritise. Say you have 49 Must Haves (very common) then how do you decide which is most important? Which is the “most must”? MoSCoW falls apart here. #2 In practice it is a binary framework In practice with MoSCoW something is either done or it is not. So why pretend at the outset that MoSCoW is anything but binary? Why not just reduce it to MW – ‘Must Have, Won’t Have?’ There isn’t leeway within the MoSCoW framework to alter the effort being made into needs depending on their relative value. Nor does it allow for changes from information emerged during the development process that altered the data the original prioritisation was made on. If you’ve worked around this in practice and you are determining value beyond the MSCW buckets then this implies that you’re actually using different measures of value (thus not MoSCoW so why use it?). #3 The keywords themselves are useless We’ve already dealt with the word now let’s move onto addressing the other keywords of MoSCoW. must, is a useless word when it comes to taking action or not taking action. You either need to do something and are able to do it, in which case do it. Or you don’t need to do something, or are unable to do something. Consider the phrase “I do some exercise”. It provides nothing little to no information to act on, not act on or better understand the situation. The reality is likely to be one of these: Should should You have established that you need to exercise and you have a plan to do it. So you do it. You don’t believe you need exercise (for implicit or explicit reasons), so you don’t do it You have established you need to exercise but you cannot make or adhere to a plan to do it. Each of these statements is more useful to work with then the statement containing . That is, you either do it or don’t do it. By saying do you’re almost lying to yourself that you will do it. should should If you could do it then why aren’t you doing it? Because it’s not important right? In that case, don’t do it because you know more important things will come up. Provides no extra information compared to or . Could: won’t must : I can actually get on board with this word. No’s are good. Won’t #4 It provides limited information for robust discussions In addition to the actual prioritisation itself, prioritisation frameworks perform another key function, enabling better communication between all the people required to make decisions and implement the solution. MoSCoW squarely fails at enabling better communication. MoSCoW provides little to no information to stakeholders about the underlying assumptions being made or the value of a need/requirement/solution. So they can’t really help. As I’ve said earlier in the article all your teammates are hearing is a yes or no, a binary signal. It’s either something we need to do or not. No why, no other information. Other frameworks provide rich information like how many customers are affected, how valuable this is to them in relation to others, what assumptions are made, how convinced you are that a given feature is needed. What do I use then? There are a range of other frameworks available that overcome some of the issues with MoSCoW. I’ve previously put together a fairly for you to evaluate what you will move to. comprehensive list of product prioritisation frameworks Best of luck. If you are stuck with MoSCoW or decide to continue using it then just take into account the problems I’ve outlined when using it. At the end of the day outcomes, communication, progress and good decisions are the key not what framework you use. F.A.Q. A little appendix. I shared the article around with some knowledgeable folks and they sent me their opinions. I discuss some of the points they made below: : “MoSCoW can and does have its place when you are looking for a binary decision of what is required to go live, or where to focus your effort when you have no data or other product framework” Feedback : But then it’s not MoSCoW, it’s MW Framework or “Must Have, Won’t Have”. Or “Yes/No Framework”. My reply : MoSCoW is still useful when building products for internal teams. Feedback : This is probably the one place where I can see it have some value but even then I’m now doubting its use. MoSCoW does give stakeholders a way to be engaged in the process. However, there are other prioritisation frameworks that provide more value here, Buying a Feature and RICE come to mind. My reply might : “That’s a bit of a rant Scott. Maybe you could try to be more constructive about MoSCoW”. Feedback The more I worked through MoSCoW the more I realised it isn’t appropriate. I used to think it had a place but now I can’t see where it fits. My reply:

Different

Mind

2022 - HackerNoon Contributor of the Year - Agile

2022 - HackerNoon Contributor of the Year - Agile Software Development

Don't talk to McKinsey, talk to Terem

Nominated for 2022 - HackerNoon Contributor of the Year - Agile

Nominated for 2022 - HackerNoon Contributor of the Year - Agile Software Development

Too Long; Didn't Read

Questions about cloud security? Get answers here.

4 Reasons You Shouldn't Use MoSCoW for Product Prioritization

Too Long; Didn't Read

Companies Mentioned

Scott Middleton

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

4 Reasons You Shouldn't Use MoSCoW for Product Prioritization

Too Long; Didn't Read

Companies Mentioned

Scott Middleton

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES