Beyond the Backlog: Understanding Prioritization with MoSCoW, Kano and RICE Frameworks

Introduction:

As seasoned product managers, we must steer the ship of feature development with a clear sense of priority. We make these decisions based on a variety of factors from the value a feature adds for our customers, the technical feasibility, aligning with business goals, to the practical considerations of time and resources required for implementation. Effectively curating our product backlog and crafting roadmaps is not just a task; it’s a strategic art that ensures the journey we chart resonates well with our stakeholders.

In this article, I am going to analyze and compare some strategies used to prioritize features such as the RICE Scoring, MoSCow model and KANO frameworks.

MoSCoW Model

The MoSCoW method is one of the simplest prioritization methods. It is used to establish a hierarchy of priorities when building features of a product. It aims to strictly establish factors like the cost of the product, requirements and qualities as early as possible.

Dai Clegg uncovered the need for a more efficient prioritization method in 1994 while consulting on software development at Oracle. At the time, teams were grappling with the challenges of Rapid Application Development, where time was a critical constraint. In response to this urgency, Clegg introduced the MoSCoW Method as a practical approach to aid teams in making strategic prioritization decisions. This method emerged as a valuable tool, providing a structured framework for teams facing time-sensitive software development projects.

Must-haves (M): These are features that the product cannot launch without. They are non-negotiable and very essential for the success of the product. For example, if you’re working on a note-taking application, the ability to save notes should be considered a Must-have. In a nutshell, These are the critical components that form the core of the product, without which the product would lack its fundamental purpose and utility.

Should-haves (S): Should haves are those features that will be valuable for the product but not critical for its core functionality. They represent the sweet spot where added value meets the core, contributing to an improved product without being indispensable for its basic operation. In the grand scheme of the product’s success, “Should haves” play a supportive role, offering enhancements that contribute to overall user satisfaction and experience.

Could-haves C): These are features that will be nice to have if the resources (time and effort) required to build them are available. They are the catchy and fun elements that, if resources permit, can enhance the overall user experience. In evaluating Could-haves, the focus is on assessing how these features might positively impact the user, adding an extra layer of satisfaction or enjoyment. While not essential for the product’s core functionality, Could-haves contribute to the overall appeal and user engagement, making them a welcomed addition if feasible.

Won’t-haves (W): Features in the category won’t make it into the current release. This doesn’t explicitly mean that the feature is “trash” or any of that sort, what it simply means is that currently, this is not the time for it and there are other priorities. The Won’t-haves category acknowledges that there may be valuable features that simply aren’t aligned with the current timeline or project scope. This distinction prevents the misconception that excluded features are of lesser importance, emphasizing that timing and context play a crucial role in feature inclusion.

Pros

• It’s very simple and intuitive
• it encourages stakeholders to focus on the essentials
• It fosters collaboration
• It helps in efficient resource allocation

Cons

• Everything can seem important to everyone

KANO MODEL

In the Kano model, features are assessed based on their potential to satisfy users, and this satisfaction is weighed against the cost of implementation. The key consideration is understanding how each feature contributes to user satisfaction and experience. By evaluating the relationship between satisfaction and cost, the product team can make informed decisions about which features to prioritize and include in the roadmap. This approach ensures a strategic alignment of user needs, project resources, and overall product goals.

The Kano model was created in 1978 by Noriaki Kano, a professor at the Tokyo University of Science, He developed this model to figure out what makes customers happy. Kano wanted to understand what factors influence customer satisfaction. By categorizing features based on their impact on satisfaction, Kano provided a valuable framework that has since become instrumental in product development and management.

Source: airfocus

Looking at the image above, we have four distinct buckets where we can classify features.

Basic Needs (Must-haves): These are basic features that are very important to the users and are mandatory. Without them, the user would be dissatisfied with the product but these features won’t necessarily excite the user.

Performance or One-Dimensional Needs (More-is-better): These are those features that directly correlate with satisfaction. The more of this type of features we give the users, the more satisfied they will be

Excitement Needs (Delighters): We can categorise these features as ones that will greatly thrill the users as they are not expected. They create this wow effect in users, for example, MTN Nigeria recently made it possible for their customers to pay for their Apple music subscription using their normal credit. It was well-received by her users.

Indifferent: Users feel neutral about these features, their presence or absence doesn’t make much of a difference. These are aspects that users don’t particularly care about, and their inclusion or exclusion doesn’t strongly influence their overall satisfaction with the product. Efforts shouldn’t be put into working on such

Pros

• Provides real insight into consumer preferences & needs
• Helps differentiate between excitement and delightful features
• It highlights market fit

Cons

• Places too much importance on customer’s opinions this doesn’t take into account, product knowledge and individual bias
• Requires a thorough understanding of the user’s expectations and it might be difficult to quantify

RICE SCORING MODEL

The RICE scoring model is both a qualitative and quantitative scoring model used to prioritize feature releases. It was invented by Sean McBride when he was working at Intercom some years back. This scoring model has 4 categories to help determine priority; Reach, Impact, Confidence and Effort

Reach: This is the number of people that will be impacted by the feature over a specific period. This can be either the Monthly average users or the number of transactions per month. It depends on the reach dynamics you set.

Impact: The impact of a feature is gauged by its influence on customers and the conversion rate associated with it. Essentially, it’s about understanding how customers will be affected when they engage with a specific feature. This evaluation encompasses both the qualitative aspect of user experience and the quantitative measure of how effectively the feature translates user interaction into desired outcomes, such as conversions.

Confidence: confidence in the RICE framework pertains to the trust you place in the estimates crafted for both the reach and impact of a feature. This metric is expressed as a percentage and reflects the degree of certainty you hold regarding the projected outcomes of the feature

Effort: This represents the effort it will take the development team to build the feature. It can be measured by the amount of human effort required or the time put in per week

Here is the formula for calculating the RICE Score

RICE = (Reach X Impact X Confidence) / Effort

Pros

• It combines qualitative and quantitative factors
• Bias is greatly reduced because of the quantitative approach
• It helps the team value their efforts

Cons

• Confidence assessment can be subjective
• It is time-consuming
• It requires accurate estimation

Let us now compare the prioritization frameworks discussed above;

1. Flexibility and Adaptability:

• MoSCoW: It’s very simple and flexible and it fosters collaboration.
• Kano Model: It might be complex and time-consuming for some teams
• RICE Framework: it offers flexibility and depth by balancing both quantitative and qualitative factors

2. User-Centricity

• MoSCoW: Doesn’t delve into user needs, Just looks at the Importance of features
• Kano Model: Places importance on customer satisfaction
• RICE Framework: Integrates user impact in its process

3. Complexity

• MoSCoW: very simple to use and implement
• Kano Model: Nuanced but requires a deep understanding of customer preferences.
• RICE Framework: Strikes a very cool balance between simplicity and depth

4. Resource Management

• MoSCoW: Not effective for resource management
• Kano Model: Doesn’t explicitly tackle resource constraint
• RICE Framework: Effective for resource management

Conclusion

In summary, the decision to employ a prioritization framework hinges on specific needs. The most effective approach often involves a mix of strategies from different frameworks or adapting them to align with your current requirements. It’s about finding a customized approach that best fits the unique context of your project or situation.