About Requirements Prioritisation Techniques

When prioritising requirements, it’s important to ensure stakeholder involvement in the process. Typically, requirements are elicited through workshops, documented sources, and existing systems and processes. They are then documented and presented back to the stakeholders for prioritisation and/or elimination from scope. This is usually done in the form of a workshop.

If time permits, prioritisation may also occur during requirements sessions. However, let’s assume that the final validation of requirements occurs after the initial gathering stage in another workshop with key stakeholders and decision makers. The objective is to prioritise requirements and processes that are more valuable to the organisation. For instance, high priority requirements may be processes that help the business increase revenue or mitigate risks. Lower priority requirements are those that provide minimal impact to organisational outputs or end user experience.

In this post I will describe 5 common requirements prioritisation techniques.

But firstly…

Weighting Requirements

With any prioritisation technique it’s good practice to combine several other criteria to weight requirements. This provides a structured framework for determining which requirement is more important than another, i.e., it helps make sensible decisions on the prioritisation. The criteria may include business importance, technical complexity, risk, and cost to implement. Ongoing cost and return on investment may also be included. The criteria for weighting requirements is determined by the stakeholders involved and may include anything that pertains to the organisational need.

I’ve used a similar approach for assessing and recommending a technology option for implementation. I provide an example of this in How to Develop a Recommendation for the Implementation of a System.

Essentially, the predefined prioritisation criteria are given a weighted score for each requirement. The higher a requirement scored, the better it is rated as a candidate for implementation.

Essential Integrations

Another factor to consider is “essential integrations”. This is where an output depends on an input, or a requirement or feature can’t exist without the other(s). Essential integrations have an impact on the prioritisation according to the above criteria because we are now looking at a pair or group of requirements and not just a siloed statement with no understanding or consideration of how it works with the whole.

It’s important to ensure that the essential integrations are identified, and the prioritisation criteria (especially risk) is defined early, so that they can be used in conjunction with a prioritisation technique discussed below.

5 Requirements Prioritisation Techniques

I asked these questions in three LinkedIn groups:

What is your preferred requirements prioritisation technique? Why do you use it?

The result is the following list covering the common requirements prioritisation techniques.

1. MoSCoW Prioritisation

The most popular answer to my LinkedIn question was MoSCoW as it is one of the most simplest techniques to use.

Here’s a YouTube video by BA Experts demonstrating how the MoSCoW technique works, Requirements Prioritization: Two Simple Techniques. And the transcript for the video is here: Transcript for Requirements Prioritization: Two Simple Techniques. It also includes a demonstration of the Needs-Based prioritisation technique which is a technique I’ve used often.

2. Needs-Based Analysis

As mentioned above, another simple technique is the Needs-Based prioritisation technique which distinguishes between what people really need versus what they would like to have. This technique is thoughtfully explained on this video, Requirements Prioritization: Two Simple Techniques.

3. Crowd Sourcing

Crowdsourcing is a way of determining what’s needed by enlisting the feedback and ideas of a large group of people. The article Why Business Analysts Need to Listen to the Crowd: Crowdsourcing Requirements Elicitation, says this:

… the guess of the crowd almost always turns out to be better than your guess, or the guess of anybody in your organization. That is why products developed with feedback from the crowd (the bigger the crowd, the better) will almost always be superior to products developed only with input from experts.

Crowdsourcing is an excellent method for incorporating the voice of the user and getting an initial prioritised list of requirements.

4. Dot Voting

‘Dot voting’ is another form of democratised feedback where each stakeholder gets typically 3-5 dots to put against one or more features. It works well when you need to understand priorities at a high level and gets stakeholders to focus on the key priorities. It’s fun way to relate to the stakeholders and have them interact in a positive way. Here’s a good article on dot voting: Prioritising requirements – how to do it and why it is critical to project success.

5. Buy a Feature

‘Buy a feature’ is another fun technique that empowers the business as they’re making the choices. It’s a great way to get stakeholder buy in. Each stakeholder gets imaginary money to spend on any features they want, and each feature being assigned a value based on its size. They collaborate to buy the most important features to be delivered within the agreed timespan. This method can produce good results. Here’s a useful article that discusses the buy a feature technique: How to play the ‘Buy a feature’ design game.

~

That’s it! There many other requirements prioritisation techniques including “weighted shortest job first (WSJF)”, which is used in agile implementations. WSJF shouldn’t be overlooked, however, my LinkedIn research produced the above five techniques as the most common.

What do you think? Should there be any other requirements prioritisation techniques on this list? Please comment below.

Thanks to everybody on LinkedIn who contributed to this post!