Software development project just like any other project has multiple requirements, budgetary constraints, and tight deadlines. Therefore, there is a need to do software requirements prioritization as it is just impossible to do everything at once. So, you need to make decisions on which set of requirements need to be implemented first and which ones can be delayed until a later release.

Normally, agile project managerswant to develop software which is both high-quality and high-value, and the easiest way to develop high-value software is to implement the highest priority requirements first. This enables them to maximize stakeholder ROI.

As normally requirements change frequently, you need a streamlined, flexible approach to requirements change management, for example product backlog (Scrum). So, in agile development, software requirements prioritization is considered a vital part of the project. And for example, to prioritize user stories we could use top 5 prioritization criteria, such as the value users place on product vision, urgency, time constraints, technical complexity, and stakeholder preferences.

Also, very often projects need to be properly prioritized for both the main project objectives and the specific tasks that will achieve the objectives. So we deal with the prioritization on two levels: product level and task level. Especially taking into account that customers normally tend not to understand that they can’t get all the features they want in release 1.0 of a new software product. Every single project should have priorities of the requested features, use cases, and functional requirements. Software requirements prioritization helps the project manager resolve conflicts, plan for staged deliveries, and make the necessary trade-off decisions.

One of the biggest differentiators between companies that thrive and those that fail is the ability to prioritize effectively, but software requirementrs prioritization is never easy. It often involves painful decisions and difficult trade-offs, and for early and expansion-stage companies, there is the added pressure of trying to accomplish a great deal with limited time and limited resources. In order to achieve growth, a team should be directed solely on the things that truly matter and are going to have maximum impact.

Software requirement prioritization is one of the biggest challenges a software team faces. Actually, 25% of tech leaders said prioritizing software development is their biggest challenge.

But according to Jeanne Ross and Peter Weill’s research for their book IT Governance, “Companies that manage their IT investments most successfully generate returns that are as much as 40% higher than those of their competitors.”

In general, companies should be sure that every team member isn’t just working on a list of tasks. They should have a clear understanding of the impact the task they’re working on has, seeing their direct contribution to the project. They also need to be clear about the purpose of the product, not only understanding the customer’s need but also the business’s value and goals.

There can be certain things like backend architecture that’s not visible for clients but for developers who can point to any architectural issues that could impact the product’s performance in the future. This is why it’s so important to make sure every engineer in the team understands the product backward and forwards.

Software requirements prioritization doesn’t have to be a constant source of pain. With the right method, it can empower your decision making and lead you to vastly improved results. Numerous methods and technologies on how to prioritize requirements have been developed as it is a very big issue for many teams and companies. Let’s look at the most popular and efficient ones:

Most popular software requirements prioritization techniques

Analyze key areas that are taken into account before taking an important decision

Benefit – an advantage that the business gets as a result of the required implementation.

Penalty – a consequence of not implementing a requirement.

Cost – effort and resources that are required to implement a requirement.

Risk – a probability that the requirement might not deliver the expected value.

Dependencies – a relationship between requirements, for example when requirement will require the completion of another requirement for its implementation.

Time sensitivity – expiry date, urgency.

Stability – the likelihood of the requirement remaining static.

Policy Compliance – requirements that must be implemented to meet the regulatory requirements.

Dependency map

It is always a good idea to create a dependency map to better understand the dependencies between the requirements. Especially taking into account, that most requirements are interdependent and you will hardly find any requirement that exists independently.

How can you do it? Let me give you an example: you have 8 requirements X,Y,Z,P,Q,R,M,O and N with priorities, on a 5- level scale where 1 is most critical and 5 least critical, as 1,2,1,4,5,1,2,2,3. So, with these priorities, it would be logical, to begin with requirements X, Z and R.

Now, let’s move to the dependency part example: we need to complete X before commencing with Y, although X and Y have the same priority levels. Similarly, we need to complete O before commencing R, although when R has higher priority than O. Understanding the requirements dependency is as just as important as prioritization. Without understanding the requirements dependency, it is highly unlikely that you will arrive at the right order of requirements implementation. So, it is a good idea to have the requirements dependency map in place before prioritizing the requirements, especially when you work on software projects.

MoSCoW

MoSCoW method works better than the numeric rating system as it is much easier for the stakeholders to rate the requirements as Must, Should, Could or Would.

The acronym represents the following:

MUST – mandatory

SHOULD – of high priority

COULD – preferred but not necessary

WOULD – can be postponed and suggested for future execution

Voting

This is the simplest way to prioritize the requirements. When there are too many requirements that need to be categorized into different categories with inputs from different stakeholders, voting is one of the best ways to sort out the prioritization of requirements. Let’s say if 10 features are under discussion, stakeholders have 10 points and they need to spread them across these features. For example, least important 1, most important 10.

Bubble sort technique

Very similar to voting, but for some people, this technique helps them get the right priority faster. To prioritize requirements using bubble sort technique, you take two requirements and compare them with each other. If you find out that one requirement has greater priority over the other, you swap them accordingly. You then continue in this way until the very last requirement is properly sorted. The result is a list of requirements that are ranked.

Hundred Dollar Method

This simple method is useful anywhere multiple stakeholders need to democratically vote on which requirements are the most important. All stakeholders get a conceptual 100 dollars, which they can distribute among the requirements. As such, the stakeholder may choose to give all 100 dollars to a single requirement, or the person may distribute the points more evenly. The higher the amount allocated to each requirement, the higher the priority of the requirement. At the end, the total is counted and the requirements are sorted based on the number of points received.

Five Whys

It often happens that stakeholders want to implement a certain feature for reasons that are not founded on logical arguments or the business interests of the company. With five whys, the analyst asks the stakeholder repeatedly (five times or less) why the requirement is necessary until the importance of the requirements is established. The answers reveal whether the requirement is really necessary or can be cancelled/postponed once the priority is determined.

So, which prioritization technique is best? There is no right answer, you can combine them, you can use one for 1 project and another one for second project. The most important is that you analyze the key points that impact the business.

Let’s look at the example of how the software requirements prioritization process may look like:

First of all what you do is creating a list of all the requirements, features, or use cases that you wish to prioritize in a spreadsheet. If certain features are logically linked, include only the driving feature in the analysis.
The second step is estimating the relative benefit that each feature provides to the customer, the business on a scale from 1 to 9, with 1 indicating very little benefit and 9 being the maximum possible benefit.
The third step is estimating the relative penalty the customer or business would suffer if the feature is not included. Again, use a scale from 1 to 9, where 1 means essentially no penalty and 9 indicates a very serious downside.
Then goes the total value – it is the sum of the relative benefit and penalty. By default, benefit and penalty are weighted equally.
What is next? Estimation of the relative cost of implementing each feature, again on a scale ranging from a low of 1 to a high of 9.
Developers estimate the relative degree of technical or other risk associated with each feature on a scale from 1 to 9.
Once you enter the estimates into the spreadsheet, it calculates a priority number for each feature and gives you the results taking into account all the inputs.
Sort the list of features in descending order by calculated priority. The features at the top of the list have the most favorable balance of value, cost, and risk, and thus should have higher implementation priority.

I hope you found this article useful if you know other software requirements prioritization techniques, please share them in the comments section below.

And if you are interested in other software development tips, I highly recommend you to subscribe to our monthly newsletter here.