GitScrum Features your IT Team will love

Join a community of Developers, Scrum Masters, Product Owners, Designers from around the world that makes the better tech products

Prioritizing Your User Stories with the MoSCoW Method

This prioritisation method was developed by Dai Clegg and first used extensively with the agile project delivery framework Dynamic Systems Development Method (DSDM).

Prioritisation using MoSCoW

Prioritization categories are acknowledged as:

Must have – User stories labeled as ‘Must have’ are critical to the project. It can also be said that ‘Must have’ items are a minimum requirement to make the product successful.

Should have – User stories labeled as ‘Should have’ are important but not critical to the project/product. Items that are not time-critical or those that have a work around can be categorized under ‘should have’.

Could have – User stories labeled as ‘Could have’ are desirable requirements but not mandatory to launch the product. These items can be added to sprints if project timescale and cost permits.

Won’t have – User stories labeled as ‘Won’t have’ are items that have a low return on investment or items that are least-critical. These items can be considered for subsequent releases based on the analysis at that point of time.

Prioritising effectively

Prior to requirements capture, the definitions of Must Have, Should Have, Could Have and Won’t Have need to be agreed with the business. Some examples are described above. However, the Must Have definition is not negotiable. Any requirement defined as a Must Have will have a critical impact on the success of the project. The Project Manager or Business Analyst should challenge requirements if they are not obvious Must Haves; it is up to the Business Visionary or their empowered Business Ambassador to prove a requirement is a Must Have. If he/she cannot, it is a Should Have at best.

Agree escalation or decision-making processes, e.g. Business Ambassador to Business Visionary to Business Sponsor, and agree the level of empowerment around decision-making at each level.

At the end of an increment, all unsatisfied requirements are reprioritised in the light of the needs of the next increment. This means that, for instance, a Could Have that is unsatisfied in an increment may be demoted subsequently to a Won’t Have, because it does not contribute enough towards the business needs to be addressed next.

How many of each priority?

When deciding how much effort should be Must Have requirements, bear in mind that anything other than a Must is, to some degree, contingency. The aim is to get the percentage effort for Must Haves (in terms of effort to deliver) as low as possible and to be wary of anything above 60%, i.e. 60% Musts Haves, 40% Should Haves and Could Haves. Won’t Haves are excluded from the calculation, as they won’t be part of this project/increment/timebox. Levels of effort above 60% for Must Haves introduce a risk of failure, unless the team are working in a project where estimates are known to be accurate, the approach is very well understood and the environment is understood and risk-free in terms of the potential for external factors to introduce delays.