This article is part of our book Agile Product Management. You can find all our best practices here.

Once you have a collection of user stories in your backlog, you need to prioritise them. If you’re working in scrum, this means you’ll need to start building your sprints and filling each one with user stories. Of course, this will remain approximative as you haven’t estimated the story point value or sizing of each story.

Your objective as a Product Owner should be to deliver the highest value stories to your users or business first. Each story has the concept of user-value baked in, as discussed in Creed #5, but it can be difficult to prioritise a story only going off this sometimes vague or very obvious value statement.

To prioritise effectively, the Product Owner must use a wide array of variables, methods and tools. In the following pages, we’ll go through some widely used and respected prioritisation methods: MoSCoW, Kano, and story mapping.


The MoSCow method is a medium-term prioritisation method. It consists in sorting your user stories into different categories:

  • M – Must have: What is described in the user story absolutely needs to be built.
  • S – Should have: The user story should be developed if possible.
  • C – Could have: Could be developed, but is not essential to users or business teams.
  • W – Won’t have: Won’t be built in the medium-term but could be useful in a later version.

Conducting a MoSCoW workshop with stakeholders from diversified backgrounds can be a great way to kick off the prioritisation of your backlog, but the approach has certain limits. Namely, participants are often in the mindset that “everything is important”, resulting in a prioritisation where everything is grouped into must have and should have. This often happens because everyone has a different perspective, and as a result, every story will seem very important to someone. It also happens in company cultures where realistic expectations are not always the norm and Product Owners and project managers don’t know how to say NO. In these cultures, participants are convinced that a placed in the “Could have” or “Won’t have” columns may as well be thrown in the bin. It’s up to the Product Owner to lead everyone into a positive mindset focused on the creation of business and user value and avoid interdepartmental or interpersonal competitivity regarding what should be built.


This method was created in 1984 by Noriaki Kano who was inspired by the asymmetry of users’ satisfaction and insatisfaction regarding a feature. Some features can only bring a small amount of satisfaction when present, but their absence can cause a large amount of insatisfaction.

If your backlog is quite mature and full, the Kano method enables you to prioritise the main features you’re looking to build into your product. This method is also collaborative and should be run in a four-step workshop with various stakeholders:

Step 1 –Identify the features you need to prioritise. Depending on your product and how granular your user stories are, keep in mind that one feature is not equivalent to one user story, but can be the sum of many stories.

Step 2 – Ask everyone in the workshop the following questions:

  • The product contains this feature, what do you think about it? (functional perspective)
    The product is missing this feature, what do you think about it? (dysfunctional perspective)

Participants choose their answers amongst the following:

  • I like it
  • I expect it
  • I am neutral
  • I can tolerate it
  • I dislike it

Step 3 – Compare discrepancies between the functional and dysfunctional perspectives and classify the features into different types:

  • Obligatory or essential functionalities (O): these are the main features of your product that cannot be left out.
  • Linear functionalities (L): Named so because adding more linear functionalities will increase the value of your product proportionally.
  • Exciting functionalities (E): Not essential, but can be a big plus and delight users.
  • Contradictory features (C): A strong difference in opinion exists amongst workshop participants. May require further digging.
  • Questionable (Q): You should try to figure out why these features are so strongly liked and disliked. Hopefully, this shouldn’t happen too often.
  • Indifferent (I): These features tend to leave people indifferent, and should obviously not be highly prioritised – hopefully, you can iterate on these features to get them into the O, E or L categories.

Step 4 – Visualise your results as a diagram

We find this approach particularly interesting as it is based on a perception of the product’s users and it has a knack for unearthing surprising expectations some stakeholders might have of a product.

Story Mapping

The visual aspect of the approach is great to help you build your backlog, and it’s also great for helping you prioritise your backlog. Namely, it gives you and your team a great way to visualise the priority of the main high-level features of your product

What’s also useful in a story map is the ability to see interdependencies between high-level features and to see prioritisation from a user journey perspective, as well as giving you a clear look at which features may be less high priority or purely technical.

In conclusion, the key to prioritising your backlog correctly is doing so with various stakeholders and understanding your product’s value, strength and weakness from varying perspectives, using a set of varied criteria. This will empower you to understand a feature’s value from a holistic standpoint, enabling you to effectively decide which features should be built first, and which can be saved for later in your product’s lifecycle.

You may also like

Read More