Prioritization Techniques (part 1): Learn 3 different ways to prioritize your stories and features

Prioritization Techniques: Why having models is helpful?

“Everything is important” – How many times have you heard this? Too many times is the right answer .

The problem with this statement is that mathematically speaking, if everything is on the same level of priority, then importance has no level of comparison, so we can also say that nothing is important and the statement will still be correct.

As a Product Manager or Product Owner, in order to deliver the desired product, ensure that the business goals are attained, and have stakeholder buy-in, you will need to prioritize by using some prioritization techniques.

To prioritize is more of an art than an exact science, and having some mental models on how to prioritize will help you both in stakeholder negotiation and management and keeping your development team focused.

In Agile software development, tackling the Budget/Scope/Time trifecta is more clear and easily followed by using Agile frameworks and implicitly implementing the principles and values mentioned in the Agile manifesto.

The delivery has implicitly defined quality, by using Acceptance Criteria and DoD ( Definition of Done ), is early reviewed and scrutinized and by early releasing.

So, usually the budget and time are maintained and we negotiate on scope, below I will show a graphic representing this

In the end, the product scope will be split in:

1. Initiatives/Themes
2. Features
3. Epics
4. User Stories

Sometimes the product may just be broken down into Epics or Features, and from these Epics or Features, we prioritize them using prioritization techniques into Releases ( see here and here for some examples where we’ve discussed release planning and roadmap planning ) and one of those Releases is an MVP ( Minimum Viable Product ) so that we can get rapid market feedback.

Epics are themselves broken down in User Stories that are User-centric requirements for the Development Team to pull into their Sprint Backlog according to their capacity and forecast. These are also prioritized using the prioritization techniques discussed below.

So to sum up, we’re going to have two categories of prioritization techniques:

1. Epics/Feature level prioritization techniques;
2. User Stories or PBIs prioritization techniques.

Please keep in mind that these might be used interchangeably at both levels (US or Feature), so there is no hard separation between one or another that should be applied.

The MoSCoW model technique

MoSCoW is an abbreviation that comes from ( Must Should Could and Won’t Do ) as can be viewed from above.

The distinction about where the categories come from is:

1. MUSTs – These are those requirements if they are not delivered, the product or project will not function accordingly or will not attain the value needed. They are those US/Epics/Features that if not delivered will not let you sleep at night. Ask yourself if these requirements are not met what happens? If the answer is: “impossible” or “cancel the project” then these are the MUSTs.
   Examples of MUSTs are:
   1. Legal, Compliance, Regulatory requirements;
   2. Major security issues;
   3. No functionality that makes the delivery viable on a specific date.
      
2. SHOULDs – Are the requirements that are important but not vital as the MUSTs. If they are left out the product can still function as it is, but if they are included they bring tremendous value.
   Examples of SHOULDs are:
   1. Non-functional improvements such as in performance or security;
   2. Major bugfixes or UI/UX improvements;
   3. New functionality that enhances the MUSTs and so on.
      
3. COULDs – This is where it gets tricky if there is no issue in distinguishing between the MUSTs and SHOULDs, the distinction between SHOULDs and COULDs is less obvious. There are some guidelines in better helping you decide between these two, but for now, let’s cover what COULDs are. COULDs are those requirements that you feel good about dropping if you are close to a deadline. These types of requirements bring minor improvements to the whole product.
   Examples of COULDs:
   1. Minor bug fixes;
   2. Minor UI/UX glitches;
   3. Enhanced functionality.
      
4. WON’Ts – These are fairly simple, if you follow the above these are usually the ones left at the end. These are the type of requirements that are not going to be delivered in the current time frame and do not impact the product’s success if left out.
   Examples of WON’Ts:
   1. AI integration;
   2. Interfacing with other products;
   3. Preference targetting.

Following a column approach where you drag the requirements into a MUST, SHOULD, COULD, Won’t have this time column, will help a lot in the initial stage:

You begin by first dragging requirements in the MUST, then follow with the SHOULD and COULDs and what is left out are going to be the WONTs.

If you correlate this technique with a Story Map described here and here you will have a very point-on prioritization to help you schedule your next releases.

The Kano model technique

The Kano model is a prioritization technique created by Dr. Noriaki Kano, focused on customers reaction towards the released features.

The two criteria in the Kano model are:

1. Impact on customer satisfaction;
2. Effort needed to implement these changes.

The features that focus on the customers desirability are broken down into:

1. Basic – Are those essential features that customers assume that are included in the product. For example, in a phone we should have contacts and a dialer for the most basic features;
2. Performance – Are the features the customers ask for as they are not always assumed to be included, going with our phone example, binding contacts to certain keypads or numbers on the dialer;
3. Excitement – Features that are not even on the customers mind but are excited to have them, e.g. with our phone, voice calling certain contacts, facial recognition and so on.

Here is how a Kano chart might look like:

As we can see from the chart above, over time Excitement/Delighter features become Performance, and Performance features become Basic as customers become more accustomed to these features and with competitive products.

The Hybrid model

Mixing MoSCoW and Kano we will get a more clearer view on how to prioritize our backlog:

MUSTs being the most important ones have been included and they represent the most basic of features, SHOULDs have been prioritized because they are easily implementable and bring a notch in performance, there are also some COULDs that will ensure a high degree of traction and maybe we will or will not do some WON’Ts.

If there is no time left, most surely we will abandon COULDs. WON’Ts are already scheduled for next release.

Feature prioritization

On a top level view, a more suitable approach for prioritizing Features is the Weighted Shortest Job First ( the WSJF prioritization model ). This model is a weighted model that uses a matrix with different weights to reach a top-down priority list.

It is mostly seen in SAFe but variations of this exist in various frameworks and methodologies under different names, using different criteria for columns to calculate priority. Marketing teams use it, sales teams use it, you can even find it in the finance department, but today we’re going to briefly walk through the simple WSJF prioritization technique.

The columns are filled one after another, so “Features” filled with features, then we jump to “User-business value”, we fill that one top-bottom for all features and so forward for all columns.

You always start by deciding on each column which feature has “1” and you go from there by comparison.

The CoD (the Cost of Delay) is the sum of the “User business value”, “Time criticality” and “RR|OE” (Risk reduction/Opportunity Enablement).

• User business value – The relative value towards the customer or business, this can be taken from the leading metrics per releases, based on previous releases and so forward, this will take a value by comparison between 1, 2, 3, 5, 8, 13, 20. That is why it is a relative value, because it is given based on metrics and agreement, what is important is to arrive at a relative value so you can make assumptions;
• Time criticality – How urgent it is, does one feature have a deadline then the rest? Is it important to release on a specific date because of market impact or competitors? Again, the higher the constraint, the higher the number;
• Risk reduction – Does this reduce a risk? Does it enable an opportunity? Be careful, sometimes an opportunity might also be a risk. Again, the greater the risk and opportunity, the greater the quotation.

Job Size – This can be the accumulated velocity points per release or an accumulated point system that also takes into consideration outsourcing and vendors and FTE’s and whatnot ( skillset, technologies and so forward ). Again this will not be expressed with something that you have on a storymap or release or product roadmap basis, but on a relative towards all the other features, again, expressed as a number between 1 and 20 ( just to keep consistency with the above ).

Now with all the details put in place, let’s run to an example using our MedicalApp:

You can find our medicalApp example, here and here. Based on the joint discussions with the stakeholders, we’ve reached the conclusion that the calendar brings the least value, is the least time critical and it doesn’t enable any opportunity so far. The job size was a relative estimate between 1 and 20 that we’ve assigned based on feature estimations, FTE’s and budget.

The final conclusion was that writing promotional content for our app came first, then the mobile application and lastly the calendar feature. (31/20 = 1.55 or 55, 21/13 = 1.61 or 61 and so forward)

Conclusion

We’ve learned that given the impact of what exactly to deliver and the multitude of ideas and requests, there is an absolute need to prioritize. We also found out several techniques one can employ to make sure we’re on target by prioritizing exactly what to include in each release.

There are also levels of prioritization, but again only your imagination keeps you in rigid borders, because the simple fact is that you can use any technique mentioned above at any level. You can use the WSJF model at story level if you want ( even thou it brings a lot of overhead, but hey…if you have time and are very uncertain, why not? ).

In the end, keep in mind that these prioritization techniques also serve well to negotiate with stakeholders, because rarely these prioritization techniques are done in private, usually and the recommended way of doing them, is with the most important stakeholders at the table.

Hope you’ve learned something new, be sure to check my next post on how to prioritize between innovation and technical debt.

Thank you!

Useful Links

• Weighted Shortest Job First
• The Professional Product Owner: Leveraging SCRUM as a competitive advantage
• The Product Manager’s Survival Guide