Each product development process has numerous requirements, often hundreds of them, or even thousands. However, every process also faces certain limitations, including budget constraints, limited resources, or tight deadlines.
As no project can count on unlimited time and resources, it’s necessary to prioritise requirements and make decisions on which of them are the most urgent and carry the most importance.
This allows the product team members to focus on the most critical requirements first and, at the same time, develop the essential elements of the project, so they align with the overall organisational vision and stay in sync with business needs.
Table of Contents
Requirements Prioritisation Techniques
The process of requirements prioritisation is not without challenges. The internal stakeholders involved in the development process, as well as customers, are likely to believe that all the requirements are important and urgent. So, while the prioritisation of the requirements is not the job the business analyst, product owner, or whoever is in charge of prioritisation should do alone, it still requires a combination of not only analytical and technical but also social skills.
The process of determining which requirements are the priority commonly includes all the key stakeholders, such as customers, clients, executives sponsoring the project, marketing and sales departments, and organisational representatives. The business analysts have to collaborate with all of them to make sure that the needs and opinions of both the stakeholders and the product team are accommodated so the prioritisation process can result in a well-run and efficient project.
Over the years, numerous requirements prioritisation techniques have been developed to make this process run more smoothly and deliver better results. Not all of them will work for every project. Some are better suited for smaller-scale projects with fewer requirements, while others are designed for more complex processes with plenty of variables and inputs from many different decision-makers. Below are some of the most popular and most often used methods for prioritising requirements.
Ranking
This is probably the one of the requirements prioritisation techniques that is the simplest and the easiest to understand. Requirements for a certain development process are ranked on an ordinal scale, with each assigned a numerical value based on its significance to the entire project and urgency.
The most important requirement will be ranked as number 1, while the least significant one will be assigned the number n, where n is the total number of requirements. As ranking can be rather subjective, this method works best on smaller projects where there’s only a single stakeholder involved. Otherwise, each stakeholder will rank the requirements that matter most to them higher, which can lead to conflicting priorities.
MoSCoW
The MoSCoW (Must, Should, Could, Won’t) is among the most widely used requirements prioritisation techniques, mainly due to its simplicity. This strategy divides requirements into four categories, each corresponding with one word from the acronym the technique is named for.
Must-have requirements are those that must be met for the solution to be successful and have the highest priority.
Should-have requirements come next and these are the requirements that are highly beneficial but not critical for the delivery of the minimum viable product.
Could-have requirements are good to have and desired but are non-essential and can be added if the time and resources allow.
Finally, Won’t-have requirements are low-priority requirements that won’t be included in the current release but may be added in the future..
Grouping (Numerical Assignments)
In this requirements prioritisation technique, requirements are categorised into different groups, based on their priority, required time and effort, costs, or whatever else is relevant to stakeholders. Therefore, you can classify the requirements by setting a different group for those that have critical, moderate, or optional priorities.
However, when you classify the requirements, it’s important to set clear criteria for categorisation so that the stakeholders have a shared understanding of the set groups. It’s a good idea to determine a percentage of requirements per group to avoid some stakeholders putting all requirements into the same category.
The downside of this method is that it lacks some nuance, as all the requirements within a certain group will have the same level of priority.
Bubble Sort Technique
The way the bubble sort technique works is that you compare two different requirements by how significant they are, and swap them in the way that the one that is more important has priority over the other.
The process of comparing proceeds until you sort the very last requirement. As a result, you’ll have a list of requirements sorted by priority.
Analytic Hierarchy Process
Developed by Thomas L. Saaty
, the analytic hierarchy process or AHP calculates the value and cost of each requirement by using pair-wise comparison and then, plotting those requirements onto the cost-value diagram. AHP allows stakeholders to break down their requirements into sets of smaller sub-problems, so they are from a hierarchy. This way, the complex goals of certain stakeholders are much easier to analyse and understand.
At each level of the hierarchy, the different elements are evaluated by comparing the parings to one another. With n the total number of requirements, the maximum number of pairings for each level is n (n-1)/2. Once the participants in the exercise make evaluations on the importance of each aspect, each element of the hierarchy can be assigned a numerical value based on their priority.
This technique is not strictly tied to the business environment and is often used in government, healthcare, and many other areas. However, as the number of requirements dictates the number of comparisons, it can be rather overwhelming and impractical when used on larger and more complex projects.
Eisenhower Decision Matrix
The Eisenhower Decision Matrix is the four-quadrant matrix, created on the basis of the two main aspects of decision-making when it comes to prioritisation: importance and urgency. Depending on their place on the diagram requirements are categorised into four priority categories, based on how important and urgent they are.
The high-priority requirements are those that are both important and urgent. These requirements can’t be left out and dealing with them can have a negative effect on the product’s success and the overall business. Commonly, these are requirements that have to do with policies, compliance, and adherence to the law.
The medium-priority requirements are urgent but not that important. They should be implemented right after the high-priority requirements. These requirements are not crucial for the project or product but are time-sensitive.
Do-these-later requirements are important but not urgent. They don’t have to be implemented immediately but are necessary at some point as the product or project will likely be a failure if they’re not fulfilled.
Low-priority requirements are not imported nor urgent and can be fulfilled if there is enough time and sufficient resources, but, if the situation dictates it, could also be completely skipped in the current project release.
Time-boxing and Budgeting
The time-boxing or fixed budgeting technique is implemented when the product team is working on a tight schedule and with a restricted budget. The basic idea is that it’s better to release the product on time even if it only has the most essential features than to have all features fully implemented but move the launch to a later date.
When this method is implemented, the requirements are classified into smaller groups based on their relative importance to the product and those that are the most essential are moved to the earlier stages of the development process to ensure that at least these core features are fully completed at the time of the product launch.
Kano Model
The kano model is used to prioritise requirements based on feedback from users. It recognises different levels of customer needs and based on that classifies the requirements into different categories, depending on how crucial they are for customer satisfaction.
Some features will result only in the basic level of satisfaction but are critical for the product functionality, so they are must-haves and have the highest priority. Others will contribute to the better performance of the product or delight the customers and their priority is determined according to the available time and resources.
The lowest priority belongs to the indifferent features that don’t deliver any meaningful value and reverse features which actively contribute to customer satisfaction. The last two requirement categories are commonly best avoided altogether.
Agile Requirements Prioritisation Techniques
The agile product development is somewhat different from the more traditional approach as the focus is on the cost vs benefit trade-off, requirements are more dynamic and frequently changing, and there’s usually a single authority for prioritising, commonly the product owner.
So, the requirements prioritisation techniques used in the agile environment will also be rather different. Prioritisation is particularly important in agile, as those projects are commonly time-boxed with a fixed set of allocated resources. Still, some of the methods listed below that have gained more popularity with the rise of the agile approach cans still be used for some more traditional projects.
Opportunity Scoring
Opportunity scoring is a highly effective prioritisation strategy in the agile environment and works by using the data from customer research to discover what the users expect from the product. The data on low and high customer satisfaction opens up a slew of new opportunities to analyse the product from their viewpoint.
Based on that, the product team can prioritise requirements and shape the development schedule so the problems that are the most important to the customers are resolved first. This allows the product team to reallocate resources toward the requirements that customers care about the most and improve other features at a later stage of the process.
Stack Ranking
Stack ranking is used to prioritise requirements and product features by evaluating how necessary or unnecessary they are. This is done by comparing the product features based on the analysis of the customer needs.
As the features you’re comparing have to go toe to toe with each other, it’s necessary to be completely objective when deciding which features deserve priority and should be moved forward in the development process.
Priority Poker
Derived from the actual card game, priority poker arranges all the requirements in order of importance, similar to what you would do with the cards before the game begins. The priority poker process involves preparing a list of tasks that need to be prioritised and arranging the point scale (volume of cards) which will be used to evaluate the importance of each task.
For this technique to be successful, it’s necessary to involve all the key stakeholders, including product managers, domain experts, strategists, and, often, even customers. This way similar to prioritising calculations that will lead to success in poker, stakeholders prioritise features that will deliver success on the market. The involvement of various stakeholders also secures objectivity and removes bias from the decision-making process.
100 Dollar Test
The participants in the 100 Dollar Test, or cumulative voting, are each assigned a fixed amount of points (or imaginary money), commonly a figurative 100-dollar bill, that they can spend by allocating a certain amount to a particular feature. When all the points or money are spent, the votes are tallied and the number of units assigned to each feature or requirement shows what should be prioritised in the product development process.
The 100-dollar test can be combined with the MoSCoW model by establishing point thresholds that would put the requirements in Must, Should, Could, or Won’t categories. As agile product development commonly includes multiple teams working on the same project, it’s important to include all of them in the voting process to ensure fair and objective results.
