Written by on 3 May 2016

The challenge of prioritising features

Teams and PO’s often have difficulties with prioritizing their user stories, epics or themes. It is not easy to define clearly what determines a specific priority. It depends on the content matter.

At Coolblue, we faced this issue while defining our roadmap. As always, everything is important and even making a business case does not solve this question. Both qualitative and quantitative arguments can be used to start with a certain part of our system.

While realizing this, we started to define on which criteria we can potentially prioritize. This enabled us to explicitly state which arguments are more valuable than others. The list we made included the following (in no particular order):

  • Remove technical dependences – this allows a company to enroll new features (earlier) and reduce time spent on maintenance.
  • Reduction of process complexity – this reduces both running costs and reduces time required to change something.
  • Reduction of risks – this will protect you from unpleasant things happening, possibly leading to more costs, delays or customers affected.
  • Current maintenance effort – which saves development and operations time.
  • Gain of efficiency – do more with less effort this saves time that can be used elsewhere.
  • Gain of revenue – this leads to more money flowing in.
  • Enable scale – this (indirectly) allows you to grow as a company, but doesn’t bring value directly.
  • Improvement of margin – this influences profit, based on the revenue you have.
  • Gain of liquidity – having money in place is handy. It influences credit ratings, and enables you to pays the bills without lending money.
  • Gain of customer satisfaction (NPS) – which will eventually lead to more products bought and a better brand position.
  • Reduction of stock – which saves warehouse space, value of goods bought (liquidity).

The most challenging part is how to prioritize several options that contain different types of value. Although you can reduce them to certain types (revenue, liquidity, risk reduction), it is not always easy to convert them directly into one single indicator like profit. Even an indicator like revenue is not directly convertible into profit, because there are many parameters in between. Calculating this is -even with the tooling we have nowadays- quite difficult.

How to deal with this?

When it comes to solving this we don’t have a final answer yet – as always. We thought of having a ‘neutral’ currency, like story points. This currency (we called it ‘beechnuts’) would derive from four or five normalized criteria. However, applying this would cause a lot of discussion (the normalization factors are highly arbitrary) and wouldn’t solve anything. This forced us to wonder why we wanted to have a ‘neutral’ currency. What would it solve? Prioritizing features will always cause discussions, with and without a ‘neutral’ currency. So perhaps the answer is not in trying to bring it to a single parameter but to better support the discussion.


This is why we choose to visualize our feature backlog and priorities in a kanban format. This facilitates discussion and helps PO’s to make clear decisions together: what does have priority and what is deferred? Based on the business value defined (revenue, risk reduction or technical dept) we discuss whether we should stop or continue items in progress, and start new items. Together we investigate, negotiate, discuss and decide on the best sequence of items. It requires good conversations to do so.

For us this works as a first step. We are always learning and evolving our approach. As such we are very curious how others approach this.So how do you prioritize features that do not have a joined currency?

REPLIES (2)What you say.

COMMENTGive your two cents.