A colleague’s statement, “In fact my tip is NEVER do a MoSCoW prioritisation,” caught my eye. “The implied fixing of scope makes change very difficult. Order things instead.” That bold NEVER waves a red flag. The following exhortation to order the things to do is also troubling to me.

I don’t know what prompted the statement. I can certainly envision situations where I think the advice to order requirements or backlog items, rather than prioritize them in buckets, makes very good sense. There are other situations where MoSCoW prioritization (“Must have,” “Should have,” “Could have,” & “Won’t have) is good enough, and situations where linear ordering is inadequate. Let’s look at it more closely…

When you’ve already got a list of things you might build, then quickly sorting them into buckets can be a great starting point. The key to making this useful is putting very few items in the Must bucket. This allows looking closely at the rest of the items to be deferred for later. If the Must bucket has many items, though, then it does indeed imply a fixed scope. I suggest addressing that issue directly.

A linear backlog can share the same problems. The same people who will over-stuff the Must bucket will often treat a linear backlog as a full set of requirements. Too often I hear comments of “it doesn’t matter which order these are, as they’ve all got to be done.”

Even when the ordering is done with more attention to priorities and a willingness to trim scope as needed, it’s hard to start the list with the absolute essentials. Often the items are overweight with non-essential add-ons. Unless these are broken down into smaller chunks of work, the Must pieces will carry the Should and sometimes Could hangers-on with them, to the detriment of the Must parts of other chunks. Every time a backlog item is split, it’s an opportunity to defer some parts of it as less essential than some other work.

Sometimes people try to split all the items at the beginning, to get them all in the proper order. I suggest it’s better to use MoSCoW buckets, first, and only split the Must items. You can probably get away with splitting fewer than that, but it’s a good improvement for those who want a “story splitting phase” to their development cycle.

Some people, Jeff Patton for example, find that a linear list is too hard to prioritize. Jeff developed the Story Map that offers a two-dimensional view. Many times this makes the prioritization of the product easier to get right. Often it needs to be linearized just-in-time for development. Sometimes I find it confuses people who visualize the work in a linear fashion. Sometimes it’s more complexity than the work warrants.

Even with Story Maps, you only want to detail the highest priority work. Which high priority work is highly variable, but you should be able to slice subsets that make sense from the tops of the columns. In most cases, there is no “one best” order for doing things, so it’s not worth spending too much effort trying to get it perfect. Just keep reviewing your decisions to see that they still make sense, as with other methods.

If you’re shooting for high maturity in your product development, you’ll want to validate your decisions with actual customers. This, of course, may make a hash of your carefully ordered work plans. When you find out that your Must Have feature isn’t valued by the market, it calls into question a lot of other priorities and assumptions. This can generate a lot of churn, but it’s better to do that churn with index cards than with software development.

Constantly testing your assumptions and plans will help you meet the market needs more closely, but it’s also more effort and time. I’m sure there are times when a simple MoSCoW approach is good enough and far more cost-effective.

And now we’ve gone full circle. All the way around, we’ve found a technique that’s better in some respect. When we’re in one context, we may decide that a higher level of complexity will pay off for us. We may even be right. It’s easy to then jump to the conclusion that this is universally applicable advice.

The more I experience in life, the less I believe that any practice is universally applicable. All of this takes thought and questioning. Are we running into a problem, here? Is there something better? Are we overlooking something? But as much as believe in examining the world around me, there are also times when it’s better to act on the beliefs of previous examining and questioning. If we are to get things done, we must balance questioning and acting.

Beware, however, thinking that any question is ever decided. It’s only decided well-enough for now.