When it comes to software development, having a well organised product backlog is key for success. However, often organising a product backlog is seen as an afterthought and plays second fiddle to the delivery of a product. Here’s a starter guide into what a product backlog is and why it is important, and tips on how to approach backlog prioritisation. But first:

What is a product backlog?

A product backlog is a list of user stories, bugs, enhancements, tasks and other work items that need to be completed to achieve the overall product vision. Product backlogs can exist on a team, project/release train, or organisational level.

So why “prioritise” prioritising a backlog?

“Prioritising” backlog prioritisation is important for several reasons. If your team does not have the story of your work mapped out, then you may encounter dependencies or other risks that might stop your team's progress. In other instances, your team might pick up work earlier than expected and this work might require revision later as requirements become more fleshed out. If your team picks up work that is low priority over work that is high priority, then they might produce a sub optimal product as everyone rushes to complete that high priority work in time.

Who is responsible for backlog prioritisation?

The short answer? It depends.

The long answer? It still really depends. On a team level, the product owner is responsible for backlog prioritisation, however the scrum master and the scrum team members can also help guide the prioritisation. On a project or organisational level, product managers, project managers, and release train engineers will manage the backlog with inputs from other key stakeholders like solution architects and SME’s.  

When does backlog prioritisation occur?

Backlog prioritisation usually takes place during backlog refinement. On a scrum team level, backlog refinement will usually occur in regular intervals. Scrum teams can also prioritise the backlog during sprint planning. On a project level, it can occur on an ad hoc basis depending on the volume of work coming in.

So, how are product backlogs prioritised?

There are numerous ways of going about backlog prioritisation, but broadly speaking these tips will help you prioritise your backlog effectively:

1. Document work items

Ensure that all your work items are appropriately documented and have enough content to prioritise them effectively. This could mean having the goals, objectives, and requirements documented.

2. Map dependencies and enablers

Make sure that dependencies and enablers are mapped out for features and user stories. This will help determine the flow of your work and help set the story of the progress of your work come sprint review time.

3. Score each work item

It is important to score each work item to gauge its value. Work items can be scored by size (time to completion), effort, priority, severity, and other metrics. Scoring systems like Weighted Shortest Job First (WSJF) can be utilised to score and eventually prioritise work items. This will help your team to determine which work items should be completed immediately, and what items can be scheduled for later. Scoring can also help determine if work items should be broken down further, which will help prioritise them better.

4. Get the capacity of the team

Ensure that you have the capacity of the team prior to backlog prioritisation. This will help ensure that the work items are not only organised according to priority, but also according to team capacity.

5. Now, prioritise!

There are many techniques to help with prioritising work items, and they can be standalone or used in conjunction with other techniques. Here is a sample:

MoScOW: organise items into must haves, should haves, could haves and won’t haves. Prioritise must have and should have items and reconsider the need for could haves and should haves.

Value vs effort matrix: plot work items based on their value and effort. Prioritise work items that have high value, but especially prioritise those items with low effort and high value. Items that are low effort may require further investigation to determine if they should be scrapped or amended.

Risk/cost analysis: prioritise items based on the cost of either delaying or not delivering them or their risk during delivery. Items with high cost and low risk should be prioritised first, while items with low cost and risk should be prioritised last.

6. Adapt, review and do it all over again

It is important to remember that backlog prioritisation is not a one-time thing. It is a continuous activity that will exist so long as you have a backlog. Whenever new or updated features and requirements come in, those work items will have to be prioritised in the backlog somewhere. While prioritising your backlog for the first time might be tricky, you will find that it will become easier as time goes on.

So, there you have it, a high-level guide on how to start prioritising your backlog like a pro!