As a Product Owner, one of your most critical responsibilities is deciding how to order Product Backlog items in the Product Backlog. With limited resources and ever-evolving customer demands, mastering the art of feature prioritization is essential to creating a successful and user-centric product. In this article, we will explore some complimentary practices which the Product Owner might use to as an input when deciding how to order the Product Backlog. These tools should be seen as optional practices that the Product Owner might use when making their day-to-day decisions about the content and ordering of the Product Backlog.
Understanding the Importance of Prioritization
Ordering Product Backlog items in the Product Backlog isn't simply about arranging them in a list. It's about making informed decisions that align with your product's vision, your business goals, and most importantly, your customers' needs. By carefully choosing which features to deliver first, the Product Owner can maximize the value that your product delivers while minimizing the risk of investing resources in features that may not resonate with your audience. The complimentary practices below can help bring clarity to your thought process and can be used to potentially involve stakeholders in the process as well.
The MoSCoW Method: Must-Have, Should-Have, Could-Have, Won't-Have
I had the opportunity to collaborate with a team on the re-platforming of a major consumer website. When we embarked on this initiative, we faced uncertainty about where to initiate our efforts. Determining the most crucial features and establishing a starting point from a technical perspective presented challenges. To gain insights from our stakeholders, we opted to employ the MoSCoW prioritization technique.
We began by compiling an exhaustive backlog of all potential features for the final product. This comprehensive list was then presented to stakeholders for feedback. Stakeholders were asked to categorize each feature according to the MoSCoW framework: "Must Have," "Should Have," "Could Have," and "Won't Have." Through productive stakeholder discussions, we gained a deeper understanding of their perspectives on feature importance.
The outcomes of the MOSCOW session proved invaluable to the Product Owner's process of ordering the Product Backlog.
Here's how it works:
This technique provides a systematic approach to categorize features into four distinct categories, denoted as follows. Engage stakeholders either remotely or in person and guide them through each feature within the Product Backlog. For each feature, prompt stakeholders to assign it to one of the following categories:
Must-Have (M): Encompassing essential features crucial for the core functionality and immediate usability of the product. These features are pivotal to fulfilling the primary purpose of the product.
Should-Have (S): Pertaining to features that, while important, aren't critical for the initial release. They enhance the user experience and contribute value, but the product can operate effectively without them.
Could-Have (C): Referring to features that provide added benefits to specific user segments. These are considered as "nice-to-haves" and can be included in subsequent releases if resource availability allows.
Won't-Have (W): Designating features that have been intentionally deprioritized. These features might not align with current objectives or could demand disproportionate resources in relation to their value.
The MoSCoW method, while a valuable tool, remains a strategic hypothesis. It's essential to recognize that the true importance to the customer only becomes clear upon product release.
Additionally, regardless of the outomes of the MoSCoW exercise, the Product Owner always remains the final decision maker on the content and ordering of the Product Backlog. The Product Owner may choose to order their Product Backlog to reduce risk, consider technical or business dependencies or may decide that certain features are more important to the customer than stakeholders believed. Whatever the Product Owner's decision, the organization should respect their decision.
The Kano Model: Customer Satisfaction and Delight
The Kano model provides a little more emphasis on how the organization hypothesizes that customers will feel about the different features which could be build for the Product. Rather than "Must Have", "Should Have", etc., the Kano Model focuses on the relationship between features and customer satisfaction.
Here's how it works:
Using, the Kano model, the Product Owner and stakeholders should review items from the Product Backlog and classify them into five categories as shown below.
Basic Needs: These are the fundamental features that customers expect. They don't necessarily impress customers, but their absence leads to dissatisfaction.
Performance Needs: These features directly correlate with customer satisfaction. The better their performance, the more satisfied customers are.
Excitement Needs: These unexpected features delight customers and can set your product apart from competitors. They aren't crucial, but they generate excitement and positive sentiment.
Indifferent Needs: These features neither significantly impact satisfaction nor cause dissatisfaction. They're often best minimized to avoid unnecessary complexity.
Reverse Needs: These features, if present, can actually lead to dissatisfaction for some users. Understanding and avoiding them is crucial.
As with all prioritization techniques, the outcome should serve as input into the Product Owner's decision-making process. The Product Owner may need to consider additional aspects such as technical dependencies or risk when they make their decisions about the content and ordering of the Product Backlog.
The RICE Method: Reach, Impact, Confidence, Effort
The RICE method is a data-driven approach that helps you quantify and compare different feature ideas. This method is particularly useful for Marketing teams who need to prioritize their efforts according to what will have the greatest impact for the largest number of people.
Many marketing teams - especially internal teams serving a larger organization - receive far more requests than they can actually fulfill. How does the Product Owner decide between the needs of the various stakeholders requesting time from the Marketing organization? The RICE method can help. RICE takes into account Reach, Impact, Confidence and Effort and can help the Product Owner make more thoughtful decisions about the content and ordering of their Product Backlog.
Here's how it works:
The Product Owner or their delegate should review requests for inclusion in the Product Backlog through the lens of Reach (how many users are impacted), Impact (how positive of an impact the feature will have), Confidence (how confident estimates are), and Effort (how much effort will it take to deliver each feature)." By considering these four elements, the Product Owner can make more educated decisions about the content and ordering of the Product Backlog.
Reach: Evaluate how many users a feature will impact. This could be a percentage of your user base or a specific customer segment.
Impact: Measure the potential impact of the feature on user satisfaction, engagement, revenue, or any other relevant metric.
Confidence: Assess how confident you are in your estimates for reach and impact. More uncertain features should have lower confidence scores.
Effort: Estimate the resources (time, money, manpower) required to develop the feature.
By calculating the RICE score (Reach × Impact × Confidence / Effort), you can prioritize features that offer the highest value relative to their cost.
Conclusion
Prioritizing features is an ongoing process that requires a deep understanding of your product's purpose and your users' needs. The MoSCoW, Kano, and RICE methods offer distinct yet complementary approaches to feature prioritization. Depending on your product, combining elements from these frameworks can provide a well-rounded strategy for making informed decisions.
Remember that context matters. Your product's stage, market conditions, and user feedback should all influence your prioritization decisions. Regularly revisit and refine your priorities to ensure your product roadmap remains aligned with your vision and responsive to changing dynamics.
By mastering the art of feature prioritization, you can steer your product towards success, delivering value to your users and achieving your business goals in a strategic and impactful way.
To learn more about the Product Owner accountability in Scrum, signup for Rebel Scrum’s Professional Scrum Product Owner course.
Expand your horizons and learn from thought leaders in Scrum and Kanban at this year’s Scrum Day conference in Madison, Wisconsin. This conference has something for everyone from our groundbreaking keynotes to break-out sessions for Scrum Masters, Executives, Product Owners, Developers and those who are just curious about Scrum.
And while you are in town, don’t miss the Badger game at Camp Randall Stadium on September 16!