Hello! Welcome back to the course.
In our last lesson, you learned how to document non-functional requirements (NFRs), which define how well a system should operate. By now, you've seen how a project can generate a long list of both functional and non-functional requirements. A common challenge, which you've likely faced in your project management roles, is that you can't build everything at once. This brings us to a crucial question: What's most important, and what should we build next?
This lesson will equip you with the tools to answer that question. We'll focus on the learning outcome: Apply prioritization techniques (e.g., MoSCoW, Kano) to a requirements backlog. Mastering these techniques is essential for managing stakeholder expectations, maximizing the value delivered by the development team, and navigating the inevitable conflicts that arise when resources are limited. This is a core competency frequently tested in business analyst interviews.
Why Prioritization is More Than Just a List
Before we dive into specific techniques, it's important to understand that prioritization isn't just about ordering items from 1 to 100. It's a strategic process for facilitating communication and resolving conflicting stakeholder needs. As a BA, you'll be at the center of these conversations.
To set the stage, let's explore how prioritization fits into the broader context of handling stakeholder disagreements.
Handling Conflicting Priorities
The article 'Handling Conflicting Priorities' by MyBrilliantBA explains that prioritization is a key strategy for resolving conflicts after communication and analysis have taken place. It frames these techniques as a tool for achieving stakeholder alignment.
Please read the first part of the article, from the beginning down to the section 'Prioritize and Weight - Based on Business Objectives'. Focus on how prioritization is presented as a step in a larger process of negotiation and consensus-building.
As the article highlights, once you've facilitated discussions and analyzed impacts, techniques like MoSCoW provide a structured framework to make and document decisions.
MoSCoW: A Simple and Powerful Framework for Alignment
The MoSCoW method is one of the most common and straightforward prioritization techniques. It's excellent for aligning a team and stakeholders around what is truly essential for a release, especially when working towards a fixed deadline. The acronym stands for:
- M - Must-Have
- S - Should-Have
- C - Could-Have
- W - Won't-Have (this time)
The image below provides a clear and practical template for how to classify requirements into these four categories.
To see how this works in a real-world team setting, let's watch a short video demonstrating the process.
Agile in Practice: Prioritisation using MoSCoW
This video from AgileAcademyAus, titled 'Agile in Practice: Prioritisation using MoSCoW', shows a team collaboratively prioritizing features for a new system. It brings the theory to life.
Watch the entire video (about 3.5 minutes). Pay attention to the role of the Product Owner, the team discussion, and the 'sanity check' at the end to ensure the 'Must-Haves' form a viable product.
The key to MoSCoW is the shared understanding it creates. The "Won't-Have" category is particularly powerful; it's not about rejecting ideas forever but about explicitly deferring them to manage scope for the current release.
Test your understanding!
You are the BA for an AdTech company building a new feature that allows advertisers to A/B test different ad creatives. Your stakeholders have provided the following list of requirements. Using the MoSCoW framework, how would you categorize them?
- The system must allow an advertiser to upload two different images for an ad.
- The system should automatically email the advertiser when the A/B test is complete.
- The system could provide AI-powered suggestions for which image is likely to perform better.
- The system must be able to track clicks and impressions separately for each ad version.
- The system should allow the advertiser to run the test for a specific duration (e.g., 7 days).
Show answer
Here is a likely categorization:
- Must-Have:
-
- The system must allow an advertiser to upload two different images for an ad. (Without this, there's no A/B test.)
-
- The system must be able to track clicks and impressions separately for each ad version. (Without this, you can't determine a winner.)
-
- Should-Have:
- 5. The system should allow the advertiser to run the test for a specific duration (e.g., 7 days). (This is important for a good user experience, but a workaround could be to have the user manually stop the test.)
-
- The system should automatically email the advertiser when the A/B test is complete. (This is a valuable notification, but the user could manually check the status.)
- Could-Have:
- 3. The system could provide AI-powered suggestions for which image is likely to perform better. (This is a "nice-to-have" feature that adds advanced value but isn't core to the A/B testing functionality.)
The Kano Model: Prioritizing for Customer Satisfaction
While MoSCoW is great for internal alignment and scope management, the Kano model provides a more sophisticated, customer-centric view. It helps you prioritize features based on their likely emotional impact on your customers. It classifies features not just by importance, but by how they influence customer satisfaction.
The following video provides an excellent and thorough explanation of the model.
The video 'The Kano Model Explained' from EPM breaks down the model's core concepts. It explains the different categories of features and how they relate to customer satisfaction.
Please watch from the beginning to 07:08. Focus on understanding the two axes (feature presence vs. customer response) and the five categories of features: Must-have, Performance, Delighter, Indifferent, and Reverse. Also, pay attention to how customer perceptions change over time.
To summarize the key categories from the video:
- Must-be (or Basic): Expected features. Customers are dissatisfied if they are absent, but not satisfied if they are present. Example: In an ad platform, the ability to see how much you've spent.
- Performance: The more you provide, the more satisfied customers become. Example: The faster your campaign reports load, the happier the user.
- Delighters (or Attractive): Unexpected features that create delight. Customers are not dissatisfied if they are absent. Example: A feature that automatically suggests new keywords for your campaign based on competitor performance.
- Indifferent: Features that customers don't care about.
- Reverse: Features that cause dissatisfaction when present.
Using the Kano model helps you focus not just on meeting basic needs but also on creating "delighters" that can differentiate your product in the market.
Combining the Models for Deeper Insight
MoSCoW and Kano can be used together to create a more robust prioritization strategy. A feature's classification in the Kano model can help inform its priority in the MoSCoW framework.
As the image shows:
- Your Must-Haves (MoSCoW) are often the Must-be/Basic features (Kano). If you don't build them, your customers will be dissatisfied.
- Your Should-Haves (MoSCoW) are frequently your Performance features (Kano). The more of these you can deliver, the more satisfied your customers will be.
- Your Could-Haves (MoSCoW) are great candidates for Delighters (Kano). These are the features that can make your product stand out.
Other Prioritization Frameworks
MoSCoW and Kano are two of the most well-known techniques, but there are many others. In an interview or a new role, you may encounter different methods. It's good to be aware of the landscape.
The article below provides a fantastic comparison table of different agile prioritization frameworks.
Agile Prioritization Techniques | Guide for Product Managers
The 'Agile Prioritization Techniques' guide from Hakuna Matata Solutions offers a concise comparison of several popular frameworks. This will broaden your toolkit and prepare you for different project contexts.
Focus on the 'Comparison of Agile Prioritization Frameworks' table. You don't need to learn each framework in depth right now, but understand the 'Best For' and 'Key Strengths' columns for RICE and the Impact/Effort Matrix. This will help you know when a different tool might be more appropriate.
Here's a quick summary of when you might use different models:
- MoSCoW: Best for projects with fixed deadlines where managing scope is critical.
- Kano: Best for customer-centric products where you want to understand user satisfaction and differentiate from competitors.
- Value vs. Effort Matrix: A quick, visual tool for identifying "quick wins" (high value, low effort). Great for collaborative brainstorming.
- RICE (Reach, Impact, Confidence, Effort): A more quantitative, data-driven method for prioritizing a large backlog when you want to reduce subjectivity.
Conclusion
In this lesson, you've learned how to move from a simple list of requirements to a strategically prioritized backlog. This is a fundamental skill that transforms a Business Analyst from a simple scribe into a strategic partner for the business.
Key Takeaways:
- Prioritization is a collaborative process for resolving conflicts and aligning stakeholders with business goals.
- The MoSCoW method (Must, Should, Could, Won't) is a simple and effective technique for managing scope and team focus.
- The Kano model provides a customer-centric lens, categorizing features based on their impact on user satisfaction (Must-be, Performance, Delighters).
- These models can be used together for more nuanced decision-making.
- Different frameworks (like RICE or Value vs. Effort) exist for different contexts, and knowing when to use which is a key BA skill.
Preview of the Next Lesson:
Now that we have a prioritized list of requirements, how do we ensure that each one is addressed and tested throughout the project's lifecycle? In our next lesson, we will learn how to create a requirements traceability matrix to track each requirement from its origin to its implementation and verification.