How to Use MoSCoW Priorities in Jira?.

26 September, 2022
A woman leading meeting in front of a whiteboard with post-its and people
Image by Jason Goodman from Unsplash

Do you want to use a custom prioritization method with your Jira projects? Implement the MoSCoW prioritization easily with the Jira priority field, let me show you how.

Different prioritization methods are available and used, but the MoSCoW method offers a simple start. Other prioritization methods are: RISE, Kano Method, Value proposition or Impact vs. Effort. I prefer to use the RISE method and sometimes the MoSCoW method, but this depends on the project and the business requirements.

As a recent poll on LinkedIn showed, that these are also the most popular methods among product and project managers.

Recent poll from LinkedIn on the popularity of prioritization methods
Recent poll from LinkedIn on the popularity of prioritization methods

What is the MoSCoW prioritization method?

This prioritization method was developed by Dai Clegg in 1994 and first extensively used in DSDM (Dynamic systems development method). The MoSCoW prioritization is a popular technique for managing requirements and their importance for the project.

The acronym MoSCoW represents four categories of work: Must-have, Should-have, Could-have, and Won’t-have, or will not have right now. Let’s look at them in detail.

1. Must-have

These provide the Minimum Usable Subset (MUST) of requirements which the project guarantees to deliver. These can be defined using some of the following:

  • Not suitable to delivering on target date without this
  • Not legal or unsafe without it
  • Cannot deliver a viable solution without it

2. Should-have

Should Have requirements are defined as:

  • Important but not vital
  • May be painful to leave out, but the solution is still viable and functional

3. Could-have

Could Have requirements are defined as:

  • Wanted or desirable but less important
  • Less impact if left out (compared with a Should Have)

4. Won’t-have

The project team has agreed on that these requirements will not be delivered (as part of the scope and timeframe). They are recorded to help clarify the scope of the project. This avoids them being informally reintroduced at a later date. Won’t Haves can be powerful in keeping the focus on the most important requirements.

Balancing the priorities

When deciding the effort allocated for Must Have requirements, remember that anything apart from a Must Have is, to some degree, contingency, since the Must Haves define the Minimum Usable Subset, which is guaranteed to be delivered.

The requirements with their assigned priority can be part of a milestone plan or roadmap. The Must Haves which are required to be delivered and guarantee the core functionality. But for example, the Should Have or Could Have would be more flexible and open for change during development.

A good starting point

Considering the project scope, budget and time constraints, the projects increments should typically not have more than 60% of Must Have efforts, where the team’s confidence to deliver is high enough.

Project requirements scope allocation according their priority

Creating a sensible pool of Could Haves (around 20%) sets the correct expectations for the business from the start – that these requirements/user stories may be delivered in their entirety in a best-case scenario. But the primary project focus will always be on protecting the Must Haves and Should Haves and deliver them on time.

Integrate the prioritization in Jira

The integration of the 4 MoSCoW priorities can be done by adding new issue priorities. For this, you first need to navigate to the Issues settings by clicking on the cogwheel in the top-right corner.

Open the issue settings

Open the issue settings

Next, click on the Priorities option in the list, to get all issue priorities.

Navigate to the Priorities page

Navigate to the Priorities page

And here you can create new priorities with the following settings:

Create new Jira priorities

Create new Jira priorities

Title Description Color URL
MUST Minimum usable subset of requirements. Cannot deliver without it #61bd4f https://raw.githubusercontent.com/Herndl/jiraicons/master/must.png
SHOULD Important but not vital; may be painful to leave out but the solution is still viable #f2d600 https://raw.githubusercontent.com/Herndl/jiraicons/master/should.png
COULD Wanted or desired but less important; less impact if left out #ff9f1a https://raw.githubusercontent.com/Herndl/jiraicons/master/could.png
WON’T Won’t have the time right now #eb5a46 https://raw.githubusercontent.com/Herndl/jiraicons/master/wont.png

Download all the icons here…