6

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'?

Carson63000
  • 10,510
  • 1
  • 28
  • 50
John V
  • 4,898
  • 10
  • 47
  • 73

4 Answers4

16

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.

pdr
  • 53,387
  • 14
  • 137
  • 224
  • All this is of course true, but the same could be said of any similar system. The true value of such frameworks is where the relative weighting of the client's shopping list of features is ill-defined. In the case of OP, this isn't quite so important given that the client has already done this up front. – Robbie Dee May 11 '13 at 15:50
  • @RobbieDee: For sure. I'm not even recommending the approach. The question was "What are the advantages?" I answered that. I assume the OP can decide for himself what to do with that information. I know I wouldn't go back to the customer and ask them to do it again. – pdr May 11 '13 at 17:20
3

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.

Robbie Dee
  • 9,717
  • 2
  • 23
  • 53
  • 3
    We changed "Would" to "Won't". That made it a lot clearer. More importantly though, using MoSCoW instead of some numbering system, makes it much easier to know what each priority stands for. After all, the priority name actually signals the priority. With numbers, the relative importance may be easier to spot, but you always have to do some translation to get at the meaning of the number/priority. – Marjan Venema May 11 '13 at 12:36
  • 1
    I have to admit, I'm struggling to see the difference between Critical, Required and Necessary. Aren't they all ways of saying "top priority?" Also, no business is going to dump anything in "Don't hold your breath." The nice-to-haves tend to be those that one person in the business thinks is useful to them, but as a business it just isn't important. Much more politik to say "well, ok, if we have time" than "yeah, you're not getting that" before the project even begins. – pdr May 11 '13 at 13:32
  • Believe me - plenty went into "Don't hold your breath" although this was for an internal IT department. Naturally, it would be unwise to tell your most profitable customers their ideas lack merit... – Robbie Dee May 11 '13 at 13:40
  • 1
    Yes, I always thought the "Would" was a very poor choice for "we are not going to do this", "Won't" is a much better choice. – gbjbaanb May 11 '13 at 14:12
  • 1
    When I was introduced to MoSCoW, the 'W' was described as "Won't (yet)". Somebody wants that feature, but we don't have time to do it in this release. It may get done in a later release. – Simon B Dec 05 '14 at 09:24
1

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.

lajos.cseppento
  • 111
  • 1
-3

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:

  1. Must have : without it the product delivery fails
  2. Should have : without it users are going to drop off from using the product
  3. Could have : if we have time left, we implement this for customer satisfaction
  4. Would have : this might be implemented in a next release, because we dont have time/budget right now
Terence
  • 103
  • 3