Prioritising requirements is one of the most important tasks in requirements lifecycle management for business analysts and it’s also a key project manager’s responsibility before moving any tasks from the product backlog to sprint backlog. The purpose of prioritisation is to ensure that the requirements effectively reflect stakeholders’ desires and capture what delivers the most value to the business. Priority can refer to the benefit of the requirements and tasks, or the impact which it will be implemented. In this article, I will outline the three most frequently used prioritisation tools in my own projects, with their pros and cons and suggest the appropriate use cases. Before diving into techniques, let’s start with the basics for prioritisation first.
Benefit
Benefit refers to the advantages that accrue to stakeholders as a result of requirements and task implementation. Depending on the nature of the benefit, each stakeholder group can perceive benefits differently. It can be both tangible, such as a specific functionality and an optimisation of user experience design, and intangible, achieving the business goal or strategic move.
Cost
Cost represents the effort and resources required to implement the requirements and tasks. It’s probably the deciding factor when faced with solutions sharing the same benefit, risks, and dependencies. Cost is often used together with other criteria (benefit) in order to embody the value of certain requirements.
Risks
Risks reflect the chances that the requirements and tasks can’t deliver the potential value, or the obstacles that prevent the requirements from being fulfilled. Risks can be imposed by both internal and external drivers. This may include many factors such as the organisation is not ready to implement the tasks due to the lack of resources and infrastructure and the difficulty of implementation because of a certain regulation came into action recently. Most organisations prefer implementing those solutions with the highest risks in order to minimise the resources that are spent before learning that a proposed solution is not technically feasible. In my projects, we always start with developing a proof of concept product for our clients to prove that the solution bearing high risks are still feasible to build up.
Time sensitivity
Time sensitivity may include the time to deliver the tasks and the time to “go live”. This criterion is often used in conjunction with other inputs as well, such as cost-benefit analysis.
Dependencies
Dependencies describe the relationship between requirements where a requirement can’t be achieved unless another requirement is fulfilled. In some cases, it might be sensitive to implement related requirements together in order to achieve efficiencies. Dependencies can be categorised into internal factors and external initiatives, which can be functional and non-functional.
Three popular prioritisation techniques listed below reflect those five bases more or less. However, each has its own features and they can complement each other at different stages of a project implementation lifecycle. Given three criteria: Ease of use, Data-driven and Balance between Business Value and Tech Nature, here is my recommendation.
1. RICE
RICE is my favourite tool when prioritising tasks and requirements with my team. With involving calculation, this technique provides a rate-scoring model for setting priorities. R (Reach) represents the potential reach to your end-users upon implementing the feature during a certain period of time. It’s a number you can extract from your user base (e.g. weekly active users; monthly active users) I (Impact) shows the level of influence exerted by the implementation of the feature. 5 scales are adopted to show the level of impact. 0.25 for “minimal”, 0.5 for “low”, 1 for “medium”, 2 for “high” and 3 for “massive high”. Based on the knowledge and the insight you have gained, you will use C (Confidence) to estimate how sure you are about the given benefit and the value that the feature could bring. 100% for “high”, 80% for medium and “50” for low. E (Effort) shows the time taken to develop such features, usually calculated as “person-months”.
Upon obtaining the rates from each category, you will use the following formula to get a rate as a result. The higher the rate, the higher the priority.
Rate=Reach*Impact*Confidence/Effort
Ease of use
As the technique is quite metric-intensive, you must obtain sufficient data at hand and the approach also involves some calculation, applying this across whole task backlog can be time-consuming. Additionally, gaining data from “Impact” and “Confidence” categories can be tricky as the team will face the challenge of taking responsibility for these decisions. As a result, no one is going to take an account for the quality of the collected data. In other words, this technique is not easy to be adopted unless the product has been rolled out for a while and the implementation process is quite mature.
Data-driven
Very data-driven! The actionable metrics and numbers are the true evidence of product progression, which provides a comprehensive picture to illustrate the potential value to be delivered once the feature is implemented.
The balance between business value and tech nature
RICE technique strikes a balance between business and tech value as both business and tech factors are taken into consideration when calculating the rate.
2. MosCoW
Standing for Must, Should, Could, Won’t, MosCow is probably the most widely used prioritisation technique due to its simplicity. In particular, it’s very popular among those organisations who have adopted the waterfall development approach. After the story points were breaking down into tasks, the tasks will then be grouped into four categories. “Must” are those tasks and features considered mandatory and they can’t be neglected. “Should” describes the features are great to have but not considered as the top priority for now. They will eventually be implemented. “Could” are those features nice to have but their absence won’t affect anything. “Won’t” are those features with the least importance and they will be phased out or revisited in the future release.
Ease of use
MosCoW is simple as it does not require any complex calculation or data collection. This also promotes mutual understanding between team and stakeholders by using flat language. It’s quick to schedule the MocCoW prioritisation session within the team.
Data-driven
Not data-driven. In most cases, stakeholders will rely on their gut feelings and expert judgement to decide the priority of the feature. Without data to facilitate the decision process, the results can be intuitive and lose the focus of the whole picture.
The balance between business value and tech nature
As the features and requirements are prioritised from most to least critical based on the value they will generate to business, stakeholders may overlook some technical constraints. The ignorance of technical constraints will put the entire release at risk as a result.
3. Value vs Complexity/Effort matrix
This technique fits perfectly when prioritising features for MVP. Similar to Eisenhower matrix, features are allocated across four quadrants and two dimensions featuring value and complexity. Tasks with the most value and lowest complexity should be prioritised to implement first. The value can be defined as market demand, customer acquisition, customer retention and potential revenue. The complexity represents the cost and effort to deliver such a feature.
Ease of use
Unlike RICE, you can use it without calculation. Even though it’s more precise if you use metrics and data to obtain results, you can still develop a perceptual map by referring to empirical research.
Data-driven
Not data-driven and it’s quite subjective…since there’s no well-specified scoring formula.
The balance between business value and tech nature
The approach takes both business and tech aspects into account, so overall it’s balanced, but not precise enough. Hence it can’t work guidance for prioritising features for mature products. However, as the technique still adopts the key principles of prioritisation, it can be used to grade features on product roadmap by product managers to build the MVP.
