Prioritisation
The product owner represents the needs of many stakeholders via the product backlog. Stakeholders wishing to make changes to a product should make a request to do so through communicating with the product owner, who will review the request and decide on whether this will be taken forward based on the need, feasibility, value and priority.
Prioritisation is a key responsibility of the product owner, ensuring that the most valuable and impactful features are delivered first. This process involves evaluating and ranking items in the product backlog based on their importance to the business and the user. Effective prioritisation helps the team focus on delivering maximum value and achieving the product goals efficiently.
The following prioritisation techniques can be used by product owners at NHSBSA:
Must Have, Should Have, Could Have, Won’t Have (MoSCoW)
The MoSCoW method categorises tasks into four groups: must haves, should haves, could haves, and won’t haves. This helps teams focus on the most critical elements first.
Pros:
- Clearly distinguishes between essential and non-essential tasks.
- Adaptable to changing priorities and requirements.
- Focus: Helps teams concentrate on delivering the minimum viable product (MVP).
Cons:
- Can be subjective, as different stakeholders might have varying opinions on what constitutes a “must have”.
- Neglect of lower priorities “could haves” and “won’t haves” might never get done.
Best Used In
Projects where it’s crucial to deliver a working product quickly, such as in agile environments or when developing an most valuable product (MVP).
Value vs. Effort Matrix
This technique involves plotting tasks on a matrix based on their value (benefit) and effort (cost) to identify quick wins and avoid time sinks.
Pros:
- Provides a clear visual representation of priorities.
- Helps identify tasks that offer the most value for the least effort.
- Can be adapted to different types of projects and goals.
Cons:
- Estimating value and effort can be subjective and inconsistent.
- May oversimplify complex tasks and dependencies.
Best Used In
Situations where quick decision making is needed and there’s a need to balance high value tasks with available resources.
Cost of Delay (work in progress)
This method calculates the impact of delaying a task or project, helping prioritise tasks that should be completed sooner to minimise impact of not doing something.
Pros:
- Provides a clear rationale for prioritisation, based on impact asessments.
- Improved decision making, enhancing resource allocation and urgency.
- Speaks clearly to stakeholders in terms of impact.
Cons:
- Can be time consuming and difficult to gather financial data needed.
- May be complex to implement and require significant effort to maintain.
- Does not consider longer term strategic goals.
Best Used In
Projects where financial impact is a critical factor, such as in external deadlines such those set by Department of Health and Social Care (DHSC).
Reach, Impact, Confidence, Effort (RICE)
The RICE method scores tasks based on Reach (number of people affected), Impact (effect on users), Confidence (certainty of estimates), and Effort (resources required).
Pros:
- Structured approach, provides a clear, quantifiable method for prioritisation.
- Encourages objective, data driven decision-making.
- Considers multiple factors, providing a balanced view.
Cons:
- Can be time-consuming to gather data and calculate scores.
- May be complex to implement and require significant effort to maintain.
Best Used In
Mature products or projects where detailed analysis and data driven decisions are essential for prioritisation.
These techniques offer various ways to prioritise work effectively, each with its own strengths and weaknesses. What they typically don’t consider is dependencies from one piece of work to another, or where work is needed to mitigate business risk – it could therefore be that a combination of methods is needed, or that the method chosen is just the starting point in prioritisation discussions.
Scoring is also not a one and done exercise – it could be that the score changes as new information is learned. It will be for the product owner and team to choose a technique that works best for them.
Improve the playbook
If you spot anything factually incorrect with this page or have ideas for improvement, please share your suggestions.
Before you start, you will need a GitHub account. Github is an open forum where we collect feedback.
Published: