3 ways to prioritize your product backlog
Anyone being a Product Manager or Product Owner knows that building a successful digital product is like building a house, with only one small difference: Building a house you actually finish at some point.
It can be your worst nightmare…the never-ending array of tasks, bugs, and user stories within a product backlog combined with daily questions when the feature will be released. Fortunately, there are methods to help you prioritize your product backlog. In this blog post we’ll cover our favorite 3:
- Impact effort matrix
- Stack Ranking
- The MoSCoW method
What’s the fuzz about?
Every Product Manager or Product Owner strives to first deliver features that bring the most value to the customer. Ironically what usually brings the most value, requires the most investigation time by the team in order to reduce potential risks associated with delivering this feature. That’s why, in the beginning, delivering these features takes more time because our knowledge is minimum. But imagine, that there is an urgent bug fix or that small product improvement that you keep sliding through each sprint or the technical upgrade that will enable the team to move faster in the future with development? What are you going to do first?
There is a trade-off that a Product Manager has to make in short-term versus long-term thinking. Should the tasks be fired out from a backlog fast but bringing less to no customer value or focus on the long-term and deliver the most important feature for the customer but after significant time invested.
You would say it’s not that easy to decide. Well, guess what? That’s not all. If you add to the dilemma the ultimate question: should the team build the right features or build the features right or the third option, building it fast?…that’s when you’re gone crazy 😊.
Ideally, you want all three, but that’s not always the cards you’ll get. Sometimes you will be in a position to build the right features with the right technology or system architecture but it will take significant time and you will miss out on the market window for launching this feature. The competitor might be ahead of you and the customer loses the exclusivity. Then opposite, you might be in a position to build the right things very fast but skipping the steps in a long run may cost you significant technical depth, refactoring efforts, or even changing the technology used. The third option, when you can build things right in a fairly fast way seems to look great, but what if you build something customers never needed nor it brings value. You are doomed.
Taking the approach from the helicopter view, it is obvious that you need to balance between the three options, but more importantly, you need to balance between the scrum roles, and here’s why. Usually, the Product Manager or Product Owner will take a stand for things that bring the most value to the customer, while the dev team will push for things built in the right way and then your stakeholders will push for deadlines and things going out fast into production.
Time is important because it means money, milestones, go-live date, etc. Moreover, by delivering things fast, you will get feedback on delivered features sooner and you will learn faster. This is a benefit that will multiply over sprints and therefore will shorten your feedback loop. But finally, what if the “loudest” stakeholder asks for one feature while the others are pushing for another? Seems like we tend to silence the loudest people in the room by servicing them first, but here’s an important lesson to learn in the Stakeholder management set of skills: it’s ok to say no.
Now, this is only a subset of possible situations happening to you on a daily basis but it’s not the end of the world because luckily there are methods proven to be efficient when prioritizing the product backlog. Here are our recommended techniques:
#1 Impact effort matrix
This technique uses 2 axes:
- Level of effort needed to accomplish the task
- Level of business impact that the task has
All tasks, user stories, bugs, or sub-tasks are divided into 4 quadrants:
- Quick wins are the tasks that have the biggest impact on the business and typically, without much extra work. This is the quadrant with the most important features and your team should focus on them first.
- Major projects come second. These are the ones that are important for the business, but they’re not very easy to do. They require high effort and probably a longer time to deliver. That’s why the team should be very careful when deciding what tasks fall into this category because you should pick only those that are worth the effort invested.
- Fill in Jobs are not that important and they fall into doing later category. Some of this work is unavoidable, but they are the kind of items you could do when you have nothing on the top quadrants. They typically don’t have a great impact on the business, but they are also very easy to do.
- Thankless Tasks are the ones in the bottom right, which are high effort and low impact. These are to be avoided, if possible because it’s probably smarter to use your resources working on something else. In the best-case scenario, you wouldn’t do these tasks at all and would simply focus on Quick wins, Major projects, and fill-in jobs, respectively.
There are plenty of templates to use when applying high effort matrix technique. The important thing is to do this exercise as a team and then you will all see what are the things to focus on first and align the expectations.
#2 Stack ranking
Stack Ranking is the most used technique, where you rank your tasks from the most important (top of the stack) to the least important (bottom of the stack). Assign the priority numbers one, then two, then three, and continue to n, the total number of items in your backlog.
The advantage of this method is that there can only be one number 1 priority task. At the same time, this is actually the hardest thing to decide. But more importantly, you compare all the tasks from your backlog to each other so the way you decide about importance is consistent throughout this exercise.
As a team, you should pick up tasks from the top toward the bottom. That way you will always work on the most important tasks.
High impact matrix in combination with the stack ranking
Some Product managers or POs decide to go for a mix of the two beforementioned techniques. Once the decision is being made what tasks will end up in what quadrant based on high impact matrix then you can use stack ranking to order the tasks within the quadrants.
This way, you get a product backlog with an ordered list of tasks, that matches the business expectations.
#3 The MoSCoW method
The MoSCoW model, credited to pioneering data scientist Dai Clegg, has roots in Agile software development.
This method got its name based on the letters that make up its criteria: Must have, Should have, Could have and Won’t have. It is very similar to Stack ranking but it has different categories of importance:
- Must Have user stories are those that you guarantee to deliver because you can’t deliver without. For example, If you would have to cancel your release if you couldn’t include it, then it’s a Must Have.
- Should Have features are important, but not absolutely vital to the success of your release. They can be painful to leave out and may have an impact on your product, but they don’t affect the minimum viability of your product.
- Could have items are those that are wanted or desirable but are less important than a Should Have item. You should work on these user stories once those in Must have and Should have are finished.
- Won’t have user stories are those in which everyone has agreed not to deliver this time around. You may keep it in the backlog for later, if or when it becomes necessary to do so.
Problems with the MoSCoW model are that it’s so easy to say what tasks fall into the Must have category while it becomes difficult for Could have or Won’t have. We tend to classify refactoring as Could have and Won’t have and that just never comes on top of our priority list.
Importance of having backlog prioritized
Once your backlog is prioritized you have a clear pathway for your team’s focus.
But don’t forget, backlog refinement is an iterative process and once you have it sorted out it doesn’t mean your work ends there…you should always refine your backlog making sure the prioritization principles you adopted are met.
