Product Backlog Prioritisation For Product Owners

Prioritizing the work of any project is an important and difficult task. Every project has limitations that have to be balanced, generally, these are time, quality, and cost, where you can only control at most two of these variables. With unlimited time and expectations for perfect quality, you can ensure the project cost will skyrocket. If you have a very specific budget and timeline, then you are going to have to sacrifice quality or features. When working with the agile values and principles, it’s up to the product owner to make the tough choices and prioritize the work to make sure that the team is working towards the product vision each sprint. The product owner and Scrum Master then work together to align the team and prepare for the next sprint.

Prioritization is important because it means putting a thoughtful approach to scheduling work. Using the product vision as the guide, the product owner looks through the work to be done and creates a plan depending on which work should be executed next. Using this plan the product owner can then align with the Scrum Master and the team to fully develop the next sprint. Along the way, the product owner will also meet with stakeholders to make sure they are informed about the team’s progress and work to realign in cases where there are new issues or new initiatives that are influencing the product. This alignment with stakeholders will mean the product owner can forge ahead and the team will feel confident they are creating a product that will be successful.

Ways to Prioritize Work

So now you have all the work laid out, it should be easy to prioritize what needs to happen next, right? This can actually be quite challenging. The first way to consider prioritizing work is to start by looking at your “epics”. Your epics are your largest user stories that usually encapsulates a set of user stories.

59 Seconds Agile - Prioritising the Product Backlog
59 Seconds Agile – Prioritising the Product Backlog

For example an epic could be “As a user I want to be able to create an account so that I can track my work in the system”, this then gets broken down into user stories that could include “As a user I want the ability to login using my email”, “As a user I want to be able to log in using a Google account authentication”, “As a user I want the ability to edit my profile picture”, and so one. All of these stories are still related to the idea of a user account though. In any project, you may have many of these epics that define a large chunk of work for one of your features. The best place to start is prioritizing these key feature sets and then work through the user stories in each of those in discrete features. This can also be a great way for the product owner to give focus to the sprint so that by the end the team has a fully functioning feature set to demonstrate.

Our Favourite Agile Books

We found these books great for finding out more information on Agile Scrum:

MoSCoW Approach

Another approach for prioritizing work is one where stakeholders and the product owner must look at the work and determine if each user story is a Must Have, Should Have, Could Have, or Won’t Have, this is usually shortened to the MoSCoW approach. This forces stakeholders to consider, given the constraints of the project, what features are critical to product success and what can be postponed for the time being. The wonderful thing about agile development is that nothing is set in stone and maybe there is a Could Have a feature that gets changed to a Must Have because the market changed or it was discovered it would be easy to implement and have a high impact for the customer. This type of prioritizing works best when the number of stakeholders is smaller and consultation with them is easy and consistent.

Kano Model

A more customer-centric way of looking at feature prioritization is by using the Kano Model. This model really puts the customer’s needs at the forefront of the discussion. This model considers the customer’s satisfaction with a product versus its functionality and this is normally done through user surveys or questionnaires.

Prev <— Continue Reading —> Next