“When everything is a priority, nothing is a priority.” – Simon Fulleringer.
We know that the product backlog is the single source of truth for any development work. A product backlog is a living document that refines over the product’s life cycle. At any given point in time, it contains new features, bugs, test requirements, and so on.
Between sprints, the product owner works with the development team on Backlog refinement, also known as grooming. This is important because the development team has a limited capacity and cannot work on all product backlog items at once.
Therefore, the product feature teams must use prioritisation techniques to decide which features provide the most value to the customers and what to focus on for the next release cycle.
This write-up will equip you with a practical understanding of four popular frameworks: Kano Model, MOSCOW Technique, WSJF (Weighted Shortest Job First), and RICE (Reach, Impact, Confidence, Effort).
We’ll break them down with simple language and relatable examples to help you make smarter decisions about your product development journey.
Delighting Users: The Kano Model
Dr Noriaki Kano, a professor of quality management at the Tokyo University of Science, created the Kano Model in 1984. The Kano Model can be a helpful framework for product teams with limited time and resources who want to make sure they are prioritising the appropriate mix of features to work on next. Dr Kano isolated and identified three levels of customer expectations.
- The basic level includes all essential features that customers assume are included in the product. A product without these features would be an unpleasant surprise to a customer. For example, a ride-sharing application allows you to book a ride, view the driver’s location, and select payment options as basic features.
- Performance-level features are those that a customer requests and are not always included in the product. The more performance features you include, the better it is from a customer satisfaction perspective. For example, a car with front airbags and a hotel with free Wi-Fi.
- Exciters include features that your customers haven’t even thought about but are thrilled about once they have them. These are unexpected “wow” features that surprise and delight users. Building on our car analogy, Android Auto or seamless smartphone integration would be another example of such a feature. These aren’t expected, but they create a positive and memorable experience.
How to use it?
The way one goes about it is by conducting a customer survey and asking the following two questions:
- Functional: “How do users feel if they have the feature?”
- Dysfunctional: “How do users feel if they didn’t have the feature?”
Responses are then plotted against functional vs dysfunctional metrics. While creating MVP, prioritise basic features first to ensure product viability. Then, balance investment in performance features with the inclusion of a few key exciters to differentiate your product.
What Matters Now: The MOSCOW Technique
In an Agile way of working, time is a fixed resource, so prioritisation is applied to requirements, tasks, feature requests, bugs, and so on. MOSCOW is a simple yet powerful technique for categorizing requirements based on their urgency and impact on a specific release or product increment.
The term MoSCoW is derived from the first letter of each of the four prioritisation categories (Must Have, Should Have, Could Have, and Won’t Have).
- Must-Have: This refers to the essential features that a project must deliver, also known as the minimum usable subset (MUS). Failing to include must-have items means the goal of the release or increment is not met. Example: For the launch of an e-commerce platform, must-have features include browsing products, adding to a cart, checkout, and secure payment.
- Should Have: This requirement is almost as important as a MUS but is not vital to the project’s success. In other words, the project’s core value proposition doesn’t depend on “should haves”. You might not want to leave it out, as it could significantly impact the project, but in the end, it can be done without causing irreparable harm. Example: User reviews and ratings, order tracking, and basic customer support features would likely fall into the “Should have” category for the e-commerce platform’s first major update.
- Could Have: The difference between a should-have requirement and a could-have requirement is simply figuring out the degree of pain that would be caused by not meeting it. That is, how will it impact the project’s business value, how many people would be affected, etc. Therefore, a could-have requirement is something you’d like but is less critical than a should-have requirement. Example: Users’ wish lists, personalised recommendations, and social sharing features could be “Could have” items for a later phase of the e-commerce platform.
- Won’t Have: Here is where you can collect those requirements that are not feasible for a specific release. Maybe next time, but the project remains strong without them. Once initiatives are placed in the ‘not have time‘ category, teams know they’re not a priority for this go-around and can put them on the back burner and out of their minds. Example: Advanced filtering options, integration with multiple social media platforms, or a loyalty program might be marked as “Won’t have” for the initial few releases of the e-commerce platform.
How to Use It?
- Collaborate with stakeholders (engineering, design, marketing, and sales) to categorize all potential features and requirements into the MOSCOW categories for a specific product release or iteration.
- Focus the team’s efforts primarily on the “Must-have” items.
- Address “Should have” items if feasible after the “Must haves” are secured.
- Treat “Could have” items as potential additions if there’s remaining capacity.
- Clearly communicate the “Won’t have” items to manage expectations.
Delivering Value Quickly: WSJF
WSJF (Weighted Shortest Job First) questions the Cost of Delay: how much will it cost the company to delay building the feature? The Cost of Delay (Cod) is a key metric that represents the economic impact of a delay in project delivery. It is a way of communicating the impact of time on the outcomes we hope to achieve.
WSJF is particularly useful for prioritising features in agile environments, focusing on maximising economic value in the shortest amount of time. It’s calculated using the following formula:
WSJF = (Value of Delay) / (Job Size)
The value of delay is a combination of business value, time criticality and risk reduction.
- Business Value: A feature that directly addresses a major customer pain point and unlocks a new revenue stream would have high user-business value. Example, Implementing a new customer onboarding flow that is projected to increase user activation rates by 15% and reduce churn by 5% in the first quarter.
- Time Criticality: How urgent is this feature? Is there a deadline, a competitive threat, or a dependency that makes it crucial? Example, Developing a feature that ensures compliance with a new data privacy regulation that goes into effect in the next three months.
- Risk Reduction or Opportunity Enablement: Does this feature reduce a significant risk or unlock a future opportunity? Example, moving from an old and legacy on-premise infrastructure to an AWS cloud-hosted environment.
- Job Size: Represents the effort required to complete the job.
WSJF = (User-Business Value + Time Criticality + Risk Reduction and/or Opportunity Enablement) / Job Size
Say, for example, the Cost of Delay for features A, B, and C is 200, 300, and 100, respectively, and the time taken to develop A, B, and C is 1 month, 2 months, and 3 months, respectively. WSJF values for A, B, and C would be 200, 150 and 33.33, respectively (formula — COD/Duration).
According to the rule, we will select the features in the following order: A, B, and C.
How to Use It?
- For each potential feature, estimate its User-Business value, Time Criticality, and Risk Reduction/Opportunity Enablement (often on a scale of 1–5). Sum these to get the “Value of Delay.”
- Estimate the “Job Size” (effort required — it could be the number of sprints).
- Calculate the WSJF score for each feature.
- Prioritise features with the highest WSJF scores — these represent the most valuable work that can be delivered relatively quickly.
Data-Driven Prioritisation: RICE
RICE provides a more data-driven approach to prioritisation by evaluating each potential feature based on the following four factors:
- Reach: How many users will this feature impact within a specific timeframe? (e.g., per month, per quarter). Use metrics like website visits, active users, or customer base. Example, Let’s say your app has 100,000 monthly active users. Based on your analysis, you estimate that 10% of these users will actively use the Product Review feature within the first month after its launch, based on user interest expressed in the research. Therefore, the Reach score for the Product Review feature would be 10,000 users.
- Impact: How much will this feature impact each user? This is often a subjective score (e.g., 1 for minimal, 3 for moderate, 5 for significant). Consider factors such as conversion rates, user satisfaction, and engagement while deciding the impact scores. Example: A feature that fixes a critical bug preventing users from completing a key task would have a high impact. Improving a shopping cart checkout experience could be termed a moderate-impact change.
- Confidence: How confident are you in your estimates for Reach and Impact? Express this as a percentage (e.g., 50% for a gut feeling, 80% based on solid data). Example: You might be highly confident in your reach estimate if it’s based on historical website analytics but less confident in the impact of a brand-new, untested feature.
- Effort: How much work will this feature require regarding person-months, story points, number of Sprints or any other unit of effort? Consider design, development, testing, and deployment efforts. Example: A minor UI tweak would require little effort, while a major back-end overhaul would require considerable effort.
How to Use It?
Consider your confidence level in the estimates to prioritise features with the highest RICE scores, as they offer the most potential impact for the least effort.
For each potential feature, estimate its Reach, Impact, Confidence, and Effort.
Calculate the RICE score using the following formula:
RICE Score = (Reach x Impact x Confidence) / Effort
When should you use each framework?
If backlog items are turning into a large, unmanaged queue, it’s time to prioritise. As pointed out, there are numerous ways to do so. Prioritisation is not a perfect science, but the important thing is to get started.
With some experience, you can also combine elements of these frameworks to create a hybrid approach that best suits your specific product, team, and context. Experiment and find what works best for you!
Leave a Reply