top of page

MoSCoW Technique

MoSCoW is a prioritisation technique used to group items by importance. It can be used to prioritise user stories, tasks, use cases, acceptance criteria, tests, or anything. In Scrum, it's most commonly used for prioritising user stories by the Product Owner and Scrum Team in Backlog refinement so that items that are more important are delivered first/early.

MoSCoW stands for:

Must have

Should have

Could have

Won't have this time


Defined as:

  • Can’t deliver without it

  • Can’t be successful without it

  • Not legal without it

  • Unsafe without it

  • Most valuable

Basically, items that have to be delivered. Whether in this release or Sprint, or later, it should be delivered before items in the other categories.


Defined as:

  • Important but not vital

  • May need some kind of workaround solution, even if only temporary

  • May be painful to leave out but the solution or iteration is still viable

Should Have differs from Could Have by the level of pain caused by not having it (Should Have being more painful). This could be in levels of business value or number of people affected.


Defined as:

  • ‘Nice-to-have’ but less important

  • Little impact if left out

Does it need to be delivered right now? No. Does it enhance the customer experience? Yes.

Could Haves may depend on the Must Haves and Should Haves being delivered first as they may hold the functionality for the Could Have item to work. For example, a catalog of items and payment functionality need to be delivered before enhancements on those items can be delivered. These items may increase in importance once you have feedback on delivered Sprints and once you have delivered their pre-requisite items.


Defined as:

  • Items that can be left out without a great impact

  • Not important for this time, but may become more important in later (in which case it may change status to one of the other categories at that time)

  • To focus, we deliberately place it out of our scope for now

These items are good to identify early (and should be easier to identify than the other items) so that you can spend more time determining the importance of items in other categories. They may eventually drop off the Backlog altogether or they may increase in importance with more feedback or changes in direction of the Product releases.



Here is an example on how to run a MoSCoW prioritisation session.

  • Using a whiteboard or virtual whiteboard, put up all the features or items on sticky notes. Draw a square with 4 quadrants with a title in each of Must Have, Should Have, Could Have and Won't Have.

  • Select one item, and get the team to vote on which quadrant they believe it is in, then put it in that quadrant. If you cannot meet a consensus, place it in the quadrant with the majority vote and mark it with a pen (or note it down) for later discussion.

  • Work through all the items, placing them in each quadrant.

  • Then review if any need to move. This may mean comparing it with items in the quadrant that it is in or being moved to. Try doing a one-on-one comparison with each item.

  • Need to ensure that no more than 60% are in the Must Have quadrant, and particularly that you are able to achieve those items.

Important note: When running a MoSCoW session, there should be no more than 60% of all the items in the Must Have quadrant. This is because not everything can be top priority and urgent. You must look at ways of labeling items as Should Haves and Could Haves by looking at whether they are essential to get your product or service to work, or just features or enhancements, or things that are dependent on Must Haves being implemented first. This is easier to do when you look at items without any emotional attachment, but rather look at functionality only.



Why do you need to prioritise by importance?

There are times when there is no other way to order items and you can’t deliver both items (or all the items). Importance may mean different things to different people and stakeholders, so it is good to understand all opinions to get a holistic, rounded view to make better decisions on what is delivered and when.

Who makes the final call on priority?

This will depend on your project or context, however if it is to do with items in the Product Backlog, then it is the Product Owner. If it is the Sprint Backlog, then the Developers need to make that call.

Why don’t you prioritise using numbers in MoSCoW?

Because it’s not an exact science. Importance is not able to be easily converted into numbers, plus you only need a general grouping with MoSCoW. You may need to use more detailed prioritisation within each quadrant after you have completed the MoSCoW technique, however under MoSCoW, you are only grouping by these importance labels.



This has been a brief overview of how MoSCoW works. For further reading on prioritisation, take a look at the following article.

This article goes into issues with prioritisation plus other ideas on how to prioritise with stakeholders.

Also refer to our Facilitation Techniques Index for a list of other techniques.

RedAgile are Australia's leading Agile Scrum training provider certified by the Scrum Alliance. As Australia's best Scrum training provider we offer Agile Scrum training courses and consulting services both online and in-person. Our training portfolio includes: Certified Scrum Master (CSM) and Certified Scrum Product Owner (CSPO) as well as our new Advanced Certified ScrumMaster (A-CSM) and Advanced Certified Scrum Product Owner (A-CSPO) courses.

World Class Scrum Training picture


bottom of page