Link back to the top of the page
Dude working in a bean bag

Prioritising Requirements with MoSCOW

The Agile MoSCoW method. No, not the city! But the unique and cool way you can prioritise requirements apart from sequencing, ordering or weighting.

Luke Pivac

/

Plexure

Prioritising Requirements with MoSCOW

What is MoSCOW?

Simply put, it is a method used in a project to help stakeholders define value by conveying a simple approach to understand the significance of a number of initiatives linked to a project or release. The acronym is broken down into four categories.

1. Must haves

These are non-negotiable product needs that are mandatory for the team. For example, the requirements such as customer ability to make secure payments.

2. Should haves

These are important initiatives that are not vital, but add significant value. For example, it could be used temporarily until a permanent solution has been met.

3. Could haves

These are nice to have initiatives that will have a small impact if left out.

Could Haves are also considered Currency used to trade off new requirements as they come to arise.

4. Won’t have

These are initiatives that are not a priority for this specific time frame and will not be delivered at this point in time.

Challenges applying MoSCoW

When applying this technique, it requires a shift in mindset. Stakeholders are challenged to put their mind in the eyes of the customer, so they can think of requirements in terms of outcomes and results. As you can appreciate, customers want everything here and now. So, as a project leader MoSCOW is a useful method to manage the challenge.

What are the steps for the groundwork?

  • Stakeholders and project team meet to align on the scope of the project, and agree on what initiatives to prioritize (this is the who, how and what). This will help define and understand at high level.
  • Consider defining and prioritizing requirements by listing the key ones first and the importance of each, then estimate the effort involved.
  • Next, the team work together and discuss how they will settle any disagreements when prioritizing.
  • Challenge the status quo. Consider all requirements as a won’t have and seek justification for it to be a must, could or should. If you could not do it, would you still release the product?
  • Must haves should be independent and not relying on could haves or should haves.
  • Lastly, once a consensus is reached, consider what percentage of resources you’d like to allocate to each category.
  • You should have no more than 60% of must haves.
Image for post
Image for post

Consider the project variables

When working out project requirements, you always have to consider time, cost and scope. AS you are aware the scope is the most flexible lever in agile. This is where you can use MoSCoW to categorize the requirements for the project scope.

Scope is your one lever that you can use to flex your muscle without compromising on quality and value.

How MoSCoW can save you

Whenever you are working on requirements gathering, think about…

Splitting requirements into functional and nonfunctional user stories

Splitting those requirements into both functional and nonfunctional requirements. For nonfunctional consider availability. security and maintain ability etc. For functional ask yourself, who can perform this, who can perform that? It is all about the criteria and planning.

The 60/20/20 rule

Once this is done, you can use MoSCoW to prioritize your requirements for the project.

As a general rule, trying aiming for a 60/20/20.

  • 60% are must haves — All meeting quality.
  • 20% should have — All meeting quality.
  • 20% exceed quality.

It is a bonus for Could haves. But a focus on 20% exceeding quality is more important.

Agile delivers on time and on budget something, preferably with must haves and should haves with a sprinkle of exceptional quality.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Article category
Project management
Subscribe to our newsletter
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.