MoSCoW - yes or no?

I was recently confronted with the question: "What is wrong with MoSCoW prioritization method?" - as a rhetorical question. The answer: "It is based on wishful thinking, the idea that when we turn something into 'Must', we somehow will have it." - effectively suggesting not to use MoSCoW. Let me take a different stand here.

As a Product Owner, I am forced to make tough calls. And I admit that I use MoSCoW as a tool.

The criticism of MoSCoW

It is correct to state that "just because someone claims something must be done, it does not mean that it will be done.". Just because my customer says we must deliver that new teleporter by the end of the month, doesn't mean he will get it.
Likewise, simply defining all work as "mandatory" doesn't mean that more will be delivered.
To suggest that people from business don't understand this is merely beating up a strawman.

Maybe they are unaware of the consequence of their action when defining a "must", and the organization is in such a mess that people don't understand the complex intricacies of what "defining as must" means.

Not a prioritization tool

MoSCoW can be very easily misused when used with the wrong question, such as "Is this a 'Must' requirement?". But that's actually just a stupid question, because everyone knows the answer will be "Yes", regardless of how important something really is. 

By using MoSCoW as prioritization tool, you will end up with a backlog consisting pretty much of 100% "Must do" stuff. Next thing you know is that everyone is blaming the team and/or PO for not doing stuff that "must be done". This approach completely destroys trust. 

Take a closer look at the four terms: They are not priorities, they are categories.  

Then, learn to ask the right question:

MoSCoW as a filter

By asking the requester/stakeholder: "What happens if we don't do it?" - the answer pretty much falls into one of the following categories: 

a) We are all dead. ("must do")

b) We will suffer a lot. ("should do")

c) Someone's uncomfortable. ("could do")

d) It doesn't matter. ("won't do")

Like this, MoSCoW can be used as a very easy, quick, reliable and comprehensible way to brush off stakeholder requests that are definitely not going to be delivered: In practice, that's everything from "C" and "W". 

Not a delivery requirement

The first thing to realize is that "Must/should" is not a priority. It also does not mean "We must/should deliver this". It should be understood as: "At this time, we understand that this must/should be added into the backlog." In due order. Weighted against all of the other stuff that is already there. The backlog only consists of "Must" or "Should" items. So, these terms are effectively worthless fill words in the context of a Product Backlog.

Just like all Java programmers know Java, the term "Java" means absolutely nothing to a group of "Java programmers" - so the words "must" or "should" means nothing in a group consisting solely of " 'must or should' items".

Backlog content

"Must", in this context, does not refer to a specific date or scope of delivery. 

It refers to being appropriate for addition to the Product Backlog.

If the PBL is too big already, the PO can suggest: "If this must go into the backlog, you need to take out one thing, because I'm not going to juggle more chainsaws than we can sensibly handle."
Like that, stakeholders can be forced to make tough decisions.

The terms "must/should" are not absolute. They becomes context-sensitive. For example, "Must do" might turn into "Must do instead of [doing something else]" or: "Must do before [doing certain other things]".

You can use a very simple sentence to explain why some "Must" item just got kicked out of the backlog; "When this issue was brought up, we decided we must add this item to the backlog. Given this new information, we decided that now we won't do any work on it."

This is a highly powerful mechanism for limiting both Scope and Work in Progress.

Used appropriately, it's a real-time adaption mechanism for keeping the Product Strategy both focused and flexible.

Summary

MoSCoW is actually a principle and not a tool: We always separate work into stuff we do - and stuff we don't do - and we always call it a day at some point. Assigning a category to "not done work" only makes this explicit. The labelling process is just turning the principle behind separation of concerns into a tool.
Like every other tool, it can be abused when understood as a tool. When used to define inclusion, you will encounter a myriad of problems.  But that doesn't mean we should throw the baby out with the bath wather.

Use MoSCoW to define exclusion. It keeps the backlog short and creates transparency on why certain things are in focus - and others are not.