A product backlog is one of the key artefacts used in software development and specifically in Agile-based frameworks. It’s used as a source of story points or tasks to complete in the next sprint. But before the tasks end up in a sprint backlog, they must be prioritized to capture what delivers the most value or looks most reasonable to complete first.
Prioritizing tasks in a project backlog is one of a product manager’s responsibilities. While you can rely on a gut feeling, such an approach usually puts your project at risk. So, in this article, we’ll discuss the most common prioritization techniques and methods, outline their main features, and suggest the best use cases for them.
When considering the prioritization method, we recommend keeping in mind the following criteria:
Simplicity. The simpler the method, the faster you prioritize.
Data-driven prioritization. Some methods rely more on assumptions than on proved data, some not. While it looks like data-driven is the way to go, there are many cases when you don’t have data or don’t have time for complex data-backed prioritization.
The balance between technology constraints and business value. It’s cool to create things that customers love and are ready to pay for. So, there are methods that put the value on top. But they may lack technical consideration. The feature sometimes looks extremely important in business terms, but equally difficult in terms of development. If the method suggests you grab the low-hanging fruit – i.e. choose tasks that will bring value fast – it may be a go-to approach.
Best use case. Prioritizing for an MVP and for a mature product may be drastically different.
That said, keep in mind that all methods below are not mutually exclusive. Across an entire product development lifecycle, they can complement each other at different project stages.
A brief comparison of popular methods of task prioritization
MoSCoW method: the simplest and most widespread approach for small products
MoSCoW is an acronym that stands for “Must, Should, Could, Won’t.” It’s arguably one of the simplest methods to evaluate the relative importance of each task. Being a part of the Dynamic Systems Development Method (DSDM) techniques, which helps companies adopt business agility practices, it’s also very popular among waterfall-based enterprises.
Features
The MoSCoW method requires breaking down all story points into four groups.
Must: These features are mandatory. Neglect any of them and the current sprint most likely fails.
Should: Features here can be described as great to have, but not top priority. Simply put, they don’t have much impact on delivery success now, though eventually, they must be implemented.
Could: These are small-scale improvements that don’t take considerable resources, but they aren’t essential. Their absence won’t affect almost anything, or at least wouldn’t do any harm to the release.
Won’t: These items are of the lowest importance. They don’t match stakeholders’ current challenges, needs, and requirements. Thus, they may be easily omitted or rescheduled for future releases.
Pros of MoSCoW prioritization
Given such operational friendliness, the benefits of MoSCoW prioritization are quite obvious.
Simplicity. The MoSCoW method doesn’t require deep understanding or complicated calculations. So, it’s easy for a team to keep in line with the whole prioritization process using a simple language. This promotes mutual understanding between team and stakeholders. Scheduling with MoSCoW is fast and transparent.
Agility for scheduling and implementation. Since this prioritization method has no strict time limits, except for the Must-have category, it allows for changing suitable timeframes per feature. That way, a team can adjust feature deliveries or releases on favorable terms.
Cons of the MoSCoW approach
With such simplicity come some challenges.
Lacks a clear consistency of implementation. Though the priorities may be easily set, the MoSCoW method does not introduce any sequencing of tasks and lacks planning. At the end of the day, it might put the entire release at risk.
Lack of big picture focus. With MoSCoW suggesting the most-to-least critical requirements or features, the stakeholders still might not see a full picture of priorities. If the focus must be concentrated on key features that are important for a business, MoSCoW may mislead the team. So, the stakeholders have to allocate business goals by themselves.
Creates imbalance between the required and slightly desirable. Often, the blurred lines between categories make it hard to decide on features that go into, say, Must and Should lists. That’s why floating tasks between all categories should be approached with great thought and care.
When to use MoSCoW
The MoSCoW method is simple but it’s not always effective. For instance, if you have a complicated backlog with many time-sensitive releases, consider choosing other methods or complementing MoSCoW with 2 or 3 more comprehensive approaches.
On the other hand, it’s quite reasonable to use MoSCoW with small products that don’t have many technical limitations and dependencies.
Kano Model: customer-driven prioritization
The Kano technique was created by the Japanese researcher Noriaki Kano in the 1980s. In a nutshell, it’s based on different levels of users’ satisfaction with a product’s features and behavior.
Features
There’s a large variety of Kano model implementations. The most fundamental and go-to version suggests dividing user backlog points by five criteria: Must-be, Attractive, One-Dimensional, Indifferent, and Reverse. As the method revolves around user satisfaction and is based on user opinion, it requires conducting Kano surveys and user interviews before prioritization practice.
Must-be: The customers consider the product functional only if these features are included.
One-dimensional: These features have a dual nature. While they aren’t a must for a product to work, they remain extremely desirable to customers. The category is closely related to foreseeing customer needs and expectation. When a product includes what customers would be happy to get, they stay satisfied. But if you fail to deliver them, users are more likely to experience disappointment.
Attractive: Features in this section add extra satisfaction, or even enjoyment and gratification. Basically, they are unexpected but nice-to-have features. On the other hand, their absence doesn’t leave customers dissatisfied.
Indifferent: The attributes here represent the least possible impact on customers satisfaction. In a nutshell, they have no value.
Reverse: The features falling into this category are considered to be the most annoying. Their presence has a rather negative effect on customer satisfaction. Alternatively, when they are not introduced, customers consider it a plus.
Pros of the Kano model
Highlighting the potential strengths and weaknesses of a product. One of the most valuable features of the Kano model is user feedback. The results of the Kano questionnaire help realize the future product’s advantages and disadvantages. It allows product managers to specify the product/market fit early in development.
Ranking product features by their value for customers. The Kano model helps rate the product properties from the value proposition standpoint and tailor it to user needs.
Cons of the Kano model
Provides no details on resources required. Although the Kano model gives a more comprehensive picture on how to establish the priorities from the customer vantage point, it doesn’t account for time and costs that are necessary for a given release or a particular feature.
Time-consuming practice. Since the Kano model originally involves the Kano survey – which may target a lot of potential customers – the efforts to process and estimate the results might be quite significant. It slows down the time-to-market and, consequently, distracts the team from execution.
Restricted by customers’ opinion and knowledge. Given that the Kano model appreciates the level of customer satisfaction, it still has pitfalls from the other side: The backlog may introduce a plain wishlist and be limited to expectations of customers who have no technical background. This caveat can lead to unstable releases. To make Kano efficient, you have to discuss the technical concepts separately.
When to use the Kano Model
If you are a startup striving to generate user feedback for the initial UX design, it will be quite efficient to submit your concept in tandem with the Kano survey. Given that it’s always better to demonstrate than describe, the combination of a prototype and the questionnaire will help distill the value. But if your product entails technical complexity and various hidden blockers, you should balance Kano or completely substitute it with more specific methods.
RICE: balanced, but time-consuming method for mature products
The RICE method is one of those involving calculations. It provides a rate-scoring model for setting priorities.
Features
RICE stands for Reach, Impact, Confidence, and Effort. These are the factors to estimate each feature separately when prioritizing.
Reach usually reflects the number of people who will use the feature or be able to use it in a particular time period. It’s assessed with real product metrics such as Daily or Monthly Active Users. E.g. if you’re assessing the improvements to a customer support page, the number of users visiting this page per month will be your reach metric.
Impact shows the feature contribution to the overall product promotion. To align them with each other, a multiple-choice scale is recommended: 3 for “massive impact,” 2 for “high,” 1 for “medium,” 0.5 for “low,” and finally 0.25 for “minimal.”
Confidence. Based on the knowledge obtained, you estimate how sure you are about the given feature benefit. Here, it is also recommended to use multiple-choice scale: 100 percent for “high confidence,” 80 for “medium,” and 50 for “low.” Anything below will mean a shot in the dark.
Effort shows the time taken by product, design, and engineering teams. This can be calculated in “person-months,” and to round it up to whole numbers usually half a month is taken as a minimum.
Upon obtaining rates from each of the categories, the following formula is applied:
RICE= Reach*Impact*Confidence/Effort
The bigger the rate is, the higher the priority.
Pros of RICE
Gives a comprehensive picture. The inclusion of such versatile factors helps formulate a fuller vision on the product and estimate its success and further promotion from different points of view.
Actionable metrics and numbers. This prioritization technique is mostly based on numbers and KPIs, which is the true evidence of product progression. The numbers can be later estimated to make improvements in further releases.
Appreciating the customer value. The used metrics concentrate on user engagement, and can also take into account the level of their satisfaction. That is to say, the RICE method considers user experience very important.
Cons of RICE
Time-consuming. The approach involves a lot of calculation. To take into account all metrics equally, grade the rates, and do calculations per each backlog item requires a lot of time.
Depends on data that you may not have. That said, the RICE method may stretch the release time. When the product or a feature is time-sensitive, but the data hasn’t been calculated yet, you either use another method or move the deadline.
Not clear about responsibility. Since the given prioritization method involves grading such factors as impact and confidence, the team faces the challenge of taking responsibility for these decisions. Consequently, it isn’t obvious who is in charge of that. Are these addressed within the whole team, or does a product owner/manager do it alone? The lines here are still blurred.
When to use
The RICE prioritization is a very efficient technique that allows for taking a comprehensive look at the product from multiple sides. However, it is not applicable in every prioritization case.
For instance, rating via RICE looks reasonable when the application has been rolled out and started its product lifecycle. As the method is quite metrics-intensive, you must have at least some data at hand. So, RICE wouldn’t work for MVP for the same reason.
Eisenhower matrix: a straightforward way for time-management
The technique originated from Dwight D. Eisenhower’s decision-making matrix, which later transformed into a four-quadrant visualization that some teams use to prioritize tasks in backlog. It’s another uncomplicated take on prioritization that you can use straight away without preparations.
Eisenhower decision matrix
Features of the Eisenhower matrix
The technique suggests allocating tasks across four different sections on the diagram. The matrix considers two prioritization dimensions – importance and urgency.
- High Priority: urgent and important.
- Medium Priority: important but not urgent. You can additionally divide this quadrant into 2 parts: The requirements on the left side are of a higher priority and must be implemented first.
- Urgent but not important. The features included are urgent but without a significant impact on a product’s business aspects, so the team must decide whether they are really needed. Similar to the medium priority part, this quadrant is also divided into 2 parts; the requirements on the left side are of a higher priority than those on the right.
- Low Priority: neither urgent, nor important.
Pros of the Eisenhower matrix
Plain. A simple structure doesn’t need multi-layered composition.
Open. The matrix doesn’t have decision dependencies and multiple results variation. So, the product team doesn’t have to think about some pitfalls when deciding what priority to put first.
Business-targeted. The method is business centric. The higher priority is given to those items that are more relevant and useful from a business point of view.
Cons of the Eisenhower matrix
No evidence base. The Eisenhower decision matrix is completely outside of a data-driven approach. It doesn’t need any calculations, metrics, KPIs, or other actionable insights to concentrate on. As a consequence, some misconceptions or discussions may occur within the product team.
May lack the technical aspect. Concentrating on a business aspect of the product, the method may, however, miss the other side – the technical one, which may affect the overall product flow and performance.
When to use
You can use the Eisenhower matrix for the whole backlog but its simple nature better fits for individual time planning, given that you have a stronger method for the whole product. Otherwise, a delivery team must agree on all requirements, their urgency, and priority.
Value vs Complexity/Effort matrix: a lightweight approach to balance tech and value
Value vs. Complexity is one of the prioritization principles used by product managers to grade features on the product roadmap. The value vs complexity (or sometimes the effort word is used) method takes a balanced approach to business and tech aspects of development.
Value vs Complexity/Effort
Features
Similar to the Eisenhower matrix, the features are allocated across four quadrants with two dimensions: value and complexity. The approach prioritizes low-hanging fruit, meaning that the most value and least complexity tasks go first. Then the matrix suggests building the highest value and the most complex features; it questions the significance of low-value items, recommending ditching complex, low-value tasks.
Value. The product team estimates the value of a feature from a long-term perspective. The value criteria are arbitrarily defined by the team rather than dictated by the method. They may be:
- market demand
- customer acquisition potential
- customer retention
- customer engagement
- expected revenue etc.
Complexity. The product team estimates a feature total cost to the business and represents it as a proxy for complexity or effort necessary to realize it. On the other hand, the team may divide the effort scoring into certain categories, such as operational costs, developer hours, time on the schedule, customer training, risks, and in-house development skills.
Pros of the Value vs Complexity/Effort matrix
You can use it without detailed calculations. Even though the matrix suggests using specific metrics, it doesn’t dictate any restrictions. If you don’t have time for specifying value and complexity metrics, you still can resort to eyeballing them.
Flexibility. As you can arbitrarily define the value, you can do the same with the second dimension. Instead of complexity, you can put risks, costs, time, etc.
Cons of the Value vs Complexity matrix
Has a subjective nature. Since there’s no well-specified scoring formula, the prioritization method is still quite open to debate.
Proves no valuable asset for a big comprehensive product. The use of the given method is quite time-consuming for big product teams with extensive product features. Additionally, it may result in high-cost coordination expenses.
When to use
It works better within the teams of smaller products and limited timeframes or budgets, especially when you build a product from the ground up. As your application matures, you may run out of low-hanging fruit and the only approach would be to embark on some bigger features. Here’s when this matrix won’t be as effective.
Weighted Shortest Job First (WSJF): lean but time-consuming way to introduce minimum marketable features
Weighted Shortest Job First is an element of the SAFe Lean-Agile framework, which tends to be used in medium-to-big companies. It suggests scoring each feature by dividing the cost of delay by job duration. At its core, WSJF is similar to Value vs Complexity, but provides more detailed guidance.
Features
Cost of Delay (CoD). This metric defines how much the company loses if the given feature isn’t implemented. Traditionally, CoD is a sum of three elements:
- User-business value – How important is the feature to business and customers?
- Time criticality – Will the user-business value reduce over time?
- Risk reduction – Does the feature reduce business and technical risks?
The values that you put into these variables must start with 1 as the lowest and the others set relative to that.
Job duration. The duration is also measured in relative points and defines the time needed for implementation.
So, in the end you get this formula:
WSJF = CoD/Job duration
The higher the rate is, the higher its priority. When the rate is calculated, features are introduced in the following order:
- Non-comprehensive features with high-added value.
- Complex features with high-added value.
- Non-comprehensive features of lesser-added value.
- Complex features with lesser-added value.
Pros of Weighted Shortest Job First
Gives accuracy and consistency. With more detailed calculation, stakeholders can expect higher consistency and predictability of results.
Focuses on increasing the ROI with limited human resources. WSJF is quite beneficial for teams with limited human resources.
Cons of Weighted Shortest Job First
Time-consuming calculations. Since the WSJF has many metrics per each backlog item, the product team is supposed to spend significant time to prioritize each task.
Limits complex tasks. If the stakeholders have a sustainable business idea, but the WSJF calculations show it’s not so urgent, they will have to postpone it, making the method a bit restrictive in implementing long-term business ideas.
Relative scales. Even though we mentioned that WSJF enables accuracy and consistency, it only works if the relative scales are set up right. Since it’s hard to align all metrics and assumptions to achieve balance, the method has room for errors.
When to use
WSJF is a great technique to assess and introduce minimum marketable features. However, you should not always rely on WSJF. For example, there are always features in the product that are supposed to be implemented by default and without any discussion.
Walking Skeleton: the best way to prioritize MVP stories
The Walking Skeleton prioritization method appeared in the early 2000s. It was advocated by Dr. Alistair Cockburn, an expert in Agile software development. The Walking Skeleton is used in prioritizing features in MVP and defines which of them are absolutely critical for the product to work.
Walking Skeleton may be smaller than the actual MVP but it puts the necessary features first
Features
The method doesn’t imply requirements falling into certain categories. However, it has distinct features that focus on user stories.
Key features first. When using the Walking Skeleton, a delivery team ranks the necessary user stories first.
The system must function. Due to the focus on the implementation of the essential points, the key functionality forms a fully operational product, without any additions.
Reflects the business concept of a future product. The Walking Skeleton advocates showing business value. That is why the story maps are lined up to display the core system elements within the restricted technical basis.
Completed with tests. Since the Walking Skeleton involves the whole production pipeline, including delivery and deployment, the testing is applied as well.
Pros of Walking Skeleton
Fast prioritization. One of the key benefits of Walking Skeleton prioritization for stakeholders is that defining the core features won’t take much time.
Key functionality only. When estimating the business value of a future product, it’s often hard to focus on the core element, as there’s always a temptation to make it as comprehensive as possible. The Walking Skeleton helps avoid this situation, putting the operating MVP with the greatest validity first.
Fast market validation. Arguably one of the most significant advantages for the Walking Skeleton is that its prioritization results help to quickly get the feedback from users. Therefore, the stakeholders assess the product-market fit and the business idea as a whole. In further releases, they can suit it up.
Cons of Walking Skeleton
Lacks important functionality. While the basic working framework is included, the Walking Skeleton will not involve other additional though still important features. It might play a critical role at some point.
Late first release. Although the Walking Skeleton is a rather quick prioritization technique, the first release won't be fast as you still must ship a functioning product.
The risk to cut corners. When trying to roll out the basic version of a product as fast as possible, the stakeholders may try to refuse the basic functional features to accelerate the release. That is why when prioritizing the backlog, the team should focus on keeping the basics without omitting them in favor of fast delivery. Otherwise, the very first – and viable – product version is at risk of turning into a prototype that is not ready for the market.
When to use
Walking Skeleton is extremely useful when releasing a Minimum Viable Product. Being good in tandem, these two can provide tangible results. However, Walking Skeleton is not the one to rely on when delivering a more sustainable and complex product with numerous extra features or additional business value. For the latter, the stakeholders should consider something more comprehensive and detailed.
To wrap up
As you may have noticed, it’s a bad idea to think that any prioritization approach is suitable for every single product or company. In a nutshell, there are few different sets of methods that fall within the particular categories of products.
For instance, if you’re building an MVP, consider combining the Walking Skeleton and Kano model. The Kano model is also a perfect match for building a prototype and gathering feedback on the UX from the target audience.
MoSCoW and Eisenhower’s decisions matrix are the best fit for prioritizing backlog requirements when building small products with some preliminary agreements. Equally efficient here is Value vs Complexity/Effort.
Working on a ready-made product with already existing lifecycle, consider RICE.
Of course, we haven’t covered many prioritization methods. For instance, many teams still rely on the HiPPO method (Highest-Paid Person Opinion). With it being stigmatized, in some cases it works, given that the team lacks expertise and ultimate understanding of a product.
Tell us what you use. Are there methods that we missed? Please share.