I do not see how the MoSCoW Method's "Must, Should, Could, Would" prioritisation is better that simply 1,2,3,4? If I receive the requirements from the customer, they already are prioritised, usually using this range. Also what is so interesting on this MoSCoW thing, why it is so 'famous'?
It's not about using acronyms at all. It's about perception.
If you ask a business to rank everything 1, 2, 3, 4 or High, Medium, Low then everything becomes a high priority. You're not really explaining, in those systems, why you're asking.
If you ask businesses to rank things as must have, should have, could have, would have, then you are simultaneously selling the point that, in all likelihood, they're not getting everything by the set release time. So, what MUST they have, for the product to even be viable? What SHOULD they have for it to be truly useful? What COULD they have, if there's time to do it? And what WOULD just be nice to have? (ie. what seems like a good idea, but they'll probably never use it.)
And, if the business do this right, and give a balanced rating, it also manages the expectations of the developers.
Rather than "Ok, let's work through the 1s and see what time we have left," it becomes very real, it becomes "the business literally cannot use this product without this pile and it's not going to benefit them much unless we can do this pile here." A useful product is a strong driving force for many developers.
Acronyms and such like often develop a greater importance than the ideas themselves. They are just hooks for remembering parts of a larger framework like DRY, KISS, SOLID, YAGNI etc.
I do agree however that in this case, it does appear to be rather contrived. Numbered priorities have always served us well in the past although there is disagreement as to how far down you go. For example, in one company I worked at, the priorities went as far as 5:
1 Critical 2 Required 3 Necessary 4 Nice to have 5 Don't hold your breath
People kind of understood the numbers but argued somewhat over the difference between Required and Necessary. In a similar way, Could and Would in MoSCoW aren't particularly clear to me.
I think the main difference bw 1,2,3,4 and MoSCoW is that you are using words, instead of numbers. Of course they can mean the same, but if you use numbers you have to clarify what does they mean. Using words are much much better, because we are people and they (should) mean something for us. Just think about: does people want a smartphone or a ph_v10.54.32 ?
And why it is so famous? Because all about is the customer. The customer tries to find out what he needs - ofc many times he can't, but it makes easier for him, then easier for the dev team.
It is an easy to remember method for prioritizing 'Critical Success Factors'. For projects with a strict deadline or budget, this could be used for each iteration for example of a SCRUM-sprint.
This list can then be transformed into a roadmap in Mantis or Trac-Server or whatever suits your needs, or even a SCRUM board.
Short abstract explenation for MoSCoW:
- Must have : without it the product delivery fails
- Should have : without it users are going to drop off from using the product
- Could have : if we have time left, we implement this for customer satisfaction
- Would have : this might be implemented in a next release, because we dont have time/budget right now