Difference between revisions of "MoSCoW"
(Zeroth version.) |
(→Cons: +{{p|spice girls question}}) |
||
(One intermediate revision by the same user not shown) | |||
Line 1: | Line 1: | ||
{{tag|requirements | {{tag|requirements}} | ||
{{tag|scrum}} | {{tag|scrum}} | ||
{{tag|agile}} | {{tag|agile}} | ||
Line 28: | Line 28: | ||
Reframe as: “We will all die if you don't build this" (20 %) "Really really really very important" (30 %), "Extremely important" (30 %) and finally "Very important" (10 %). | Reframe as: “We will all die if you don't build this" (20 %) "Really really really very important" (30 %), "Extremely important" (30 %) and finally "Very important" (10 %). | ||
The {{p|spice girls question}} in combination with full capacity utilization is both more effective and efficient. | |||
==Sources== | ==Sources== | ||
*http://pl.coremag.eu/uploads/media/RQNG_Tom_Gilb_core_ENG_05.pdf | *http://pl.coremag.eu/uploads/media/RQNG_Tom_Gilb_core_ENG_05.pdf |
Latest revision as of 10:01, 25 December 2013
MoSCoW is a clustering technique, not a prioritization strategy. So it can't be used as a prioritization strategy. The most obvious con of MoSCoW is that people tend to use it to prioritize even though that's just wrong on so many levels. It's best to use a different prioritization strategy. Remedy: Sandwich two should haves and a could have between every five or so must haves. It works wonders. It's the proven "salami technique" honed by politicians throughout the ages.
Beware of the widely misunderstood W means Won't have, not something as meaningless as Would have. Ironically, in dsdm W originally read "would have liked to have but won't have this time". So there is an explicit category for what you are not going to require.
MoSCoW doesn't help with the question “What should the team work on now?” For this you need a(n) (strictly) ordered list of (work) items like the product backlog.
Another con to MoSCoW (or any other similar classification) in my experience is that the assignment
of an 'M' tends to be subjective. Especially if multiple POs are involved. Every PO believes 'his' M is
more important than any one from the other POs.
By assigning (business) value the discussion is more about 'How do obtain this-and-that value?' instead of 'Mine is more 'M' than yours' and makes the discussion more constructive.
Pros
- relatively easy scale to use
- focus only really works because of your choices of what NOT to do.
Cons
- everything becomes an M—MoSCoW only works if you put a cap on the amount/percentage of items you're allowed to classify as M.
- The very fact that we rank 'full items' in a manner that says "MUST", or less desirable states, the idea of slicing the very thing has become less obvious. Especially when things are MUST, we tend to believe from that point on that this item is not negotiable anymore. Hence the fact that typically MUST-HAVES are more fixed than they should be, in terms of feature richness. Maybe it is our brain saying: “This is a MUST, so we need to fix the whole thing…”
- MoSCoW is set of priority groups and in no way does it help you to specify the value that you aim to achieve nor does it help to generate ideas to incrementally delivery value.
Reframe as: “We will all die if you don't build this" (20 %) "Really really really very important" (30 %), "Extremely important" (30 %) and finally "Very important" (10 %).
The spice girls question in combination with full capacity utilization is both more effective and efficient.