In product development, a backlog is a prioritized list of features, bugs and tasks (often referred to as “tickets” or “tasks”) that a team plans to work on in the future. The list is always changing as circumstances evolve and more knowledge surfaces.
A lot of teams split their backlogs up. And why might you do this? We wrote a guide to highlight the key differences between sprint and product backlogs.
Product managers, with the input from development, QA and other business stakeholders, own the prioritization and organization of the backlog. That doesn’t mean they need to write every ticket in the backlog but for each item they should be able to answer the following set of questions to aid in determining priority.
How to determine priority
What is the goal of this task?
A ticket for a new feature will often include a user story so that product, development and QA understand what the ultimate goal of the task is.
What opportunities does this task enable for the customer or the business?
This question is often overlooked because there might not be much perceived value delivered to the customer or the business right away but dividends can come later from these types of efforts.
What value does this bring to the customer or business?
The ultimate goal of all work should be to make progress towards solving customer problems while thriving as a business in a mutually beneficial way.
Does this reduce our risk in any meaningful way?
Some tasks don’t necessarily bring obvious benefits to customers but the business might need to dedicate some resources to reducing future risks. For example, they might need to plug a security hole before it’s exploited and customer data is breached or the business is sued.
How urgent is this task?
Even though customers might be demanding a particular feature, a version of the code might need to be updated first before it’s no longer supported. So even though it’s not immediately valuable for the customer, it still needs to be done before a certain deadline.
How much effort will this take to implement?
This question is not easy for a non-technical PM to answer alone which is why regular backlog refinement should be done in conjunction with a lead developer. When developers can identify tasks in the backlog that are quick-wins, product managers should seriously consider ranking that higher in the list.
Is the task clearly defined?
Development teams will often start working on the next task on the top of the backlog only to discover that the requirements, designs or technical specifications are incomplete or not clear. Not all items in the backlog need clear definition but if they are getting close enough to the top that a developer might be working on it soon then it should be. PM’s should work closely with design and development to ensure upcoming tasks are ready.
How severe and widespread is this issue?
When looking at bugs or needed UI-improvements, product managers should be weighing how many users are experiencing the issue against how severe the issue is. Good judgment should be used when determining whether a minor issue that is affecting all users should be addressed before or after a major issue that is affecting a few users.
Here are some methods to consider when ranking the priorities of a backlog:
- Weighted Shortest Job First (WSJF)
- Impact vs Effort Matrix
A trap some product managers fall into is to favor chasing new features but then they neglect to address the tech-debt and technical investments that long-term, healthy products require. One of the benefits of holding backlog refinement sessions every sprint is so that development can be a voice for the technical needs and priorities of the product.
Product managers should view the prioritization of the backlog as a constant negotiation. They should be cautious not to be so rigid as to rarely allow new things into their backlog but they should also not be so fluid that the direction is drastically changing on a regular basis. When all things are a priority, nothing is a priority.
Backlog formats
You can write a backlog using many different formats. Some teams are happy to use wiki tools like Confluence or Notion, whereas others prefer a flat list of tickets using a tool like Jira.
Check out Ant Murphy’s post on some creative backlog formats. His number one format is a user story map. Here’s an example of one in Avion:
A user story map leads to a totally user-centric backlog that all stakeholders can get behind. Read more about story mapping.