How to Prioritise Your Product Backlog

‍This article will cover the following topics:

1. Product Manager: More mad skills than a cat herder
2. What is the Product Backlog?
3. What are the Product Backlog tasks?
4. The importance of prioritising your backlog
5. 5 things no one mentions about prioritising the product backlog
6. Method 1: Impact effort matrix
7. Method 2: Stack Ranking
8. Method 3: The MoSCoW method
9. Method 4: Weighted Shortest Job First
10. Method 5: Data-driven prioritisation
    

Product Manager: More mad skills than a cat herder

Enter the product manager as the unsung hero as the person who has to herd cats and bring everyone and every task together to ensure that deadlines are met, tasks are ticked off, code deployed, and products released. It's not just about keeping everyone focused and to deadline, but being agile enough to strengthen tasks and targets, and the demands of managers and users change. Any good product manager should be intimately acquainted with their product backlog, but how do they decide what to focus on and when?

This article takes a look at the different methods for product backlog prioritisation. It's not selling a particular framework, workshop, or ideology. Instead, it provides an opportunity to look at the different ways people interpret and prioritise the product backlog.

What is the product backlog?

A product backlist is a list of tasks required to meet the strategic plans of the product road map. The backlog is about turning that sky-high thinking into actionable tasks, including how-to and by whom. While the product roadmap is big-picture, presenting high-level goals and strategies intended for a CXO audience, a product backlog is the nuts and bolts to-do list, writing (arguably) for those who carry out the bulk of the work - product and development teams. 

What are the product backlog tasks?

Product backlog tasks differ depending on the team. Those using a scrum ideology may refer to 'a user story'. This puts each specific product backlog task into the perspective of the end-user. For example:

"As a (user type) I want to (what they want to accomplish) so that I can (the result they want to achieve)." 

However you frame them, these typical tasks or stories can include: 

• Bug fixes
• Infrastructure and feature updates
• Developing new features 
• Infrastructure updates
• Changes to existing functionalities
• Bug fixes
• Reducing technical debt
• Refactoring
  

The importance of prioritising your backlog

Your product backlog should be a list of all the product-related tasks your team needs to complete, including the division of responsibility and the time frame. The problem is that the list is not intended to be conclusive. It needs to be flexible and will change according to the other things that are happening. For example, a hotshot product release by a competitor may mean you need to release a product update earlier than expected to compete, meaning everything else gets pushed back.

Even events such as attending conferences (virtual or in-person) may mean that teams may prioritise sales and marketing visible tasks in an effort to connect with new customers. But the problem occurs when tasks keep getting pushed below the list, and the product manager struggles to maintain momentum to review and organise all the tasks in preference and priority. An effective product backlog list needs to be well structured, organised to be easily read and understood, and arranged to meet the company's strategic needs. 

5 things no one mentions about prioritising the product backlog

As mentioned, there are plenty of people who have made money out of organising developers and will want to sell you their "fail-proof" method. Still, there are also plenty of resources bolted onto services you already use. But first, I'd like to make a few points. Whatever methods you choose, five things are necessary to make it work:

• The company has a reasonable level of functionality. High staff turnover or absenteeism makes it hard to get tasks completed. I once worked in a company where my department had five different managers in five months. Every time a new one started, the tasks and priorities changed. 
  

• The product manager is respected and in a position of authority. This means when they set deadlines or allocate tasks, they are treated as if they were set by the CTO and CEO (or if you're a freelancer, the person who processes your invoices.)
  

• The CXO/Senior management are hands-off enough to allocate responsibility to the product manager and good communicators - if something needs to change, they are able to articulate the reasons instead of simply pulling rank. 
  

• Team members are appropriately skilled to complete the tasks (or the company is receptive to hiring higher-skilled freelancers). 
  

• There is a process for managing technical debt - especially if it is slowing down teams, causing bugs, and delaying feature releases. If technical debt is not a priority, it will be harder to reduce the product backlog or complete tasks.

Techniques to prioritise the product backlog

1. Impact effort matrix

The impact effort matrix plots tasks on a matrix with two axes: level of effort and level of impact. I've seen it done in meetings using a whiteboard and post-it notes. There are also templates in edraw, miro, and sketchbubble. It's a good exercise involving team members from different departments as you get an opportunity to pit the different priorities against each other.

Not convinced? Itamar Gilad shares a well-critiqued analysis of the Impact/Effort matrix that is definitely worth a read.

2. Stack Ranking 

One of the commonly used methods is stacked ranking—the act of taking your list of items that need prioritisation and ranking them from the most important (top of the stack) to the least important (bottom of the stack).

Advantages? There can only be one number one. This method guarantees you’re always delivering the highest value you can, and your team is never working on low-value features. Plus, it's easy to use.

Disadvantages? The priorities will most likely be determined using your intuition backed up with some analytics.

3. The MoSCoW method 

The MoSCoW method is an alternative to prioritising things in terms of High/Medium/Low

The categories are:

• Must have: these tasks are critical to the current delivery timebox in order for it to be a success. If even one 'Must have' requirement is not completed, the project delivery should be considered a failure.
• Should have: Important but not crucial for delivery.  
• Could have: these tasks are desirable but not necessary and are to be prioritised only if other things are completed. 
• Won't have: these tasks are the least-critical. 

Great chart by KECG‍

The problem with the MoSCoW method is that it doesn't help you choose if you, for example, have three tasks in the 'Must have'. Further, it's easy to see new builds prioritised over refactoring if refactoring is always delegated to the 'could have' or 'won't have' categories. 

4. Weighted Shortest Job First

The weighted-shortest-job-first' (WSJF) principle is used in agile software development to prioritise jobs based on the economics of Lean product development. This is achieved by dividing the Cost of Delay by the time taken to complete the tasks. For example, if I prospective featured would be worth $150k per month, a delay of three months would mean a Cost of Delay of $450K.

There are many different mathematical ways to frame this, but another way is thinking about what a company will lose if something is not attended to or completed. The task that if not done results in the most significant loss - this could mean financial and reputational, loss of subscribers, an inability to upsell a related product or bottleneck such as a task delaying multiple releases. There'll always be a level of subjectiveness, of course, but perhaps less than trying to determine what task is the most important to whom.

5. Prioritise based on context

Stepsize is an editor-first issue tracker for a healthy codebase built for Engineers. If you’re looking for a sustainable solution for tech debt management in your engineering team, you need Stepsize. If you have a messy backlog and want to start actually addressing technical debt, this is ideal for you.

• Create & view code issues directly from your editor
• Track & prioritise code improvements like technical debt
• Add key issues to your sprints with our Jira integration
• Address key technical debt and ship 50% faster

Ok, we've prioritised our backlog. Now what?

Think about the platforms you already use for communications and managing tasks and projects. This is especially important with remote teams, particularly those in different time zones, meaning work happens asynchronously. Regularly clean up your backlog. As Maarten Dalmijn suggests, "the best way to prevent a Product Backlog from going stale is by keeping it small and fresh."

‍
Don't add to your team's cognitive load by making them use yet another workflow platform. Instead, make your tools work for you.

We're building Stepsize AI, the AI companion for software projects.

Stepsize AI has a long-term "memory" of the context around your projects from Jira, GitHub and Slack.

It offers powerful summaries of what happened in your project, actionable suggestions on what to do next, and can answer pressing questions in seconds.

We think it's a game-changer. Try out Stepsize AI here.

‍