Stop Using MoSCoW on Your Agile Projects

Thoughts By 2 years ago

The majority of my career as an agile practitioner I’ve seen project managers guide their product owners down the wrong path using MoSCoW to organise the product backlog. Sadly, I have also guided product owners down this path to disastrous results. MoSCoW is the acronym for ‘Must-Have’, ’Should-Have’, ‘Could-Have’, and ‘Wont-Have’. What inevitably happens is the product owner tags over 80 percent of the stories as must-have features. The project manager will be left wondering ’so, what exactly is the priority’ and will need to do additional work to prioritise the Must-Have features.

“An Environment of Entitlement rather than Collaboration”

MoSCoW is a terrible way to prioritise a product backlog. The problem isn’t just its usefulness as a prioritisation tool but also in the paradigm that it sets up between the product owner and the team. When the product owner says they “must-have” or “should-have” a story or feature it creates an environment of entitlement rather than collaboration. MoSCoW puts the team in a servant to master relationship with the product owner. The teams job becomes to fulfill the demands of a product owner who likely doesn’t understand what his customers really want. This approach is especially damaging when building untested end user products.

A more collaborative way to manage a product backlog is business value; particularly the precious metals scale. The precious metals scale is a model I discovered while doing a product backlog refinement exercise during a training session. The basic idea is to tag stories as Platinum, Gold, Silver or Bronze. If necessary you can even add Copper as a 5th metal. This is a simple but powerful analogy for business value because it links the value of the precious metal to that of the feature in which the team is discussing. An added benefit is the creation of a collaborative paradigm between the product owner and the team as the team is no longer working for the product owner but the product owner working with the team to create value.

Agile is about responding to change and customer collaboration. MoSCoW unknowingly creates a contract between the product owner and the team which is likely to create a hostile environment and a poor product. Business value creates transparency and collaboration. Whether using the precious metals business value scale or creating your own, be sure you gather this information from the customer or the end user. The next best source is someone who works closely with the end user. Business value ensures that your team is working on the highest priority items and not simply meeting the demands of an out-of-touch product owner.

  • Tim

    Great article Reggie, and I’m going to start following the b2cloud blog on a regular basis! As an alternative (or maybe adjunct) to the precious metals scale, is market research / user testing a valid way to prioritise user stories? e.g. have a research sample of users apply the precious metals scale to the stories?

  • TomasDeceuninck

    Hi Reggie, I think the problem you are describing has nothing to do with the use of MoSCoW but has more to do with the business mindset. Any prioritisation tool/system can result in a “a servant to master relationship” if collaboration/communication is not managed. Introducing a new system merely results in refocusing everyone on the fact that they have to work together to determine priority, which is a good thing of course, but the system was not the root cause. imo, don’t blame MoSCow (or any other prioritisation system for that matter), blame the poor communication/project management for not maintaining an open relationship between business and development.