Who and how to prioritize product backlog?

Backlog, backlog on the wall, what is the priority of items all? How to organize your backlog and how to decide what items have priority? Your backlog is real and it contains:

• Bug fixes
• Developing new features
• Infrastructure and feature changes
• Changes to existing functionalities
• Technical debt and refactoring

Even though this sounds like backlog is just a list of what the team should do, it is not. There are some of the properties in every team that differs from a to-do list. Therefore, a scrum backlog is also:

• List of requirements where every requirement adds value to the end-user
• Set of organized and prioritized items
• Set of estimated entries
• A living document that is changing and developing throughout the project development

Why prioritize product backlog?

You should prioritize product backlog because it provides a better understanding of project progress. Your backlog should clearly show which tasks bring the most benefits and which could cause the biggest losses. It also shows strategies for solving them in future sprints.

It might feel intuitive to know what tasks are a priority. But when, for example, a new project occurs, you push tasks below the list. In such cases, it is hard to maintain the preference and priority of the tasks. However, for successfully managing the project, you should prioritize your backlog and make it effective.

Who makes a final decision on prioritizing the product backlog??

There are many team members working on a product backlog – Leap Developer, Scrum Master, Product Owner, and a whole Development team. However, in most cases, a product owner is the person solely responsible for the product backlog prioritization. They describe top-level entries to the team and determine which ones are the priority.

Normally, the product owner will gather input and feedback about the progress. Their job is to be lobbied by various stakeholders. However, it is ultimately his decision on what the team will build.

Product Roadmap vs Product Backlog

Both product backlog and product roadmap are a job that you need to do in upcoming sprints. They both are important documents that are changing with project development.

However, they are not the same. A backlog is a sum of tactical details about the project, while the product roadmap is a strategic document. A product roadmap is a broader plan for project development and it doesn’t contain epic and user stories.
A too detailed product roadmap is difficult to understand, prone to change, and hard to manage. That is the reason why we keep high-level features in the product roadmap and details in the product backlog.

Some more differences between roadmap and backlog:

The product roadmap contains high-level plans, while the product backlog is task-orientated and contains requirements and user stories.
A product roadmap is helpful to stakeholders and the executive team, while a product backlog is a document helpful to the development team.
The product roadmap shows your strategy, while the backlog implements it.

Product backlog and product roadmap in sync

Even though they are not the same, product backlog and product roadmap should be synchronized. Since the product backlog influences the product roadmap, a bigger product backlog can change the product roadmap. Further, if the development process is not anticipated, you might need to change for example due to date, and update the product roadmap within.

A good practice is to use the product roadmap to determine the backlog contents and track backlog changes while reviewing the product roadmap. Regular checking should involve the development team and stakeholders.

Product Backlog vs Sprint Backlog

Both product and sprint backlog are contained within an artifact. Artifacts are an agile component that provides information about the product. It is a higher-level document that includes product backlog, sprint backlog, and product increment.

A product backlog is a list of activities that the team should complete in the project. As you have read earlier in the article, it can include features, issues, bug fixes, and non-technical requirements. On the other hand, the sprint backlog is a specific list of product backlog items that belongs to the current sprint.

Further, the sprint backlog tells you what functionalities you should deliver in that sprint. The items within can be divided into smaller chunks of work, such as tasks. Depending on their skills, team members can tackle these tasks.

When the team finalizes the sprint, they estimate the remaining product backlog to prepare for the next sprint. The work that is completed and meets the definition of done, goes in product increment. The responsibility of the product owner, again, is whether to release it or not.

How to prioritize backlog?

There are many ways to help yourself in making a final decision on prioritizing the product backlog. Based on your preferences, you can choose priority intuitively, starting from short-term use one of many methods and techniques.

Set a bucketing system for organizing items

Find one way of organizing and setting priorities that will be used by your team in the whole project. With having it clear what the organizing rules are, it will be easier for all team members to contribute. You can choose between Refined – To Be Refined – Not Prioritized, Large – Medium – Small, and MoSCoW method of prioritization.

MoSCoW method includes categories:

• Must have: tasks that are critical for delivery on the due date. Must have tasks influence other tasks, and another task cannot be completed otherwise. The project’s success depends on must-have tasks.
• Should have: Important tasks but not crucial for project delivery.
• Could have: tasks that are desirable but not necessary. They can become a priority only if other things are finished.
• Won’t have: tasks that are the least important.

Schedule Short Term Tasks First

One of the ways to organize and prioritize product backlog is to schedule short-term tasks first. This approach is called weighted-shortest-job-first (WSJF) principle. The WSJF model prioritizes jobs based on their economical value. In other words, you divide the cost of delay by the time taken to finish these tasks. Tasks that could cause the biggest losses are a priority.

For example, if a specific feature’s economical value is $100 per month, then a cost of delay of three months would be $300.

You can calculate the cost of delay in many other ways too. But what they all have in common is – the amount of money that the organization will lose if something is not delivered in time.
Sometimes the delay of feature delivery causes indirect costs. For example, reputational loss, a decrease of subscribers, or inability to upsell. This loss as well accumulates financial losses and you should prioritize which of them is the most crucial in the project.

Separate low priority items

To have an overview of product hierarchy and high strategic values, JadeALM provides you with an automatically synchronized WBS chart. It helps you to understand what tasks are more important and what is less important in a very quick look. No need to spend minutes looking for some dependency or tasks.

In a bunch of product information, it is easy to misplace important ones and less important ones. That is why it is a good idea to have a separate place for low-priority items. For example, you can keep them in very low positions on the WBS chart.

Or, to have a special list of items that are more like ideas than necessities. For example, a place in the editor with the headline “Great Ideas”, or maybe a “Longer-Term Tasks” list.

Some more catchy criteria for backlog

INVEST CRITERIA

The same criteria that work for user stories also work for making the final decision on prioritizing the product backlog. INVEST stands for Independent, Negotiable, Valuable, Estimable, Small and Testable.

• Independent user stories in the backlog should be self-contained. Make sure that there is no inherent dependency on another user story.
• Negotiable user stories in backlog stand for backlog that is not a rule, but possible to change. Backlog is part of an iteration, and it can always be changed and rewritten.
• Valuable user story in the backlog means that it must deliver value to the end-user.
• Estimable user story or requirement is a chunk of work that you can estimate.
• Small enough user stories in the backlog should finish in 3 to 4 days of work. You can split bigger “Epic” stories into smaller ones and follow the INVEST agile approach.
• Testable user story or its related description must provide the necessary information to make test development possible.

DIVE CRITERIA

Another criteria for managing backlog is DIVE. It stands for Dependencies, Insures against risk, Business value, and Estimated effort.

• Dependencies in the product backlog are rare. However, when your backlog includes them, they have a great impact on the rank ordering. Because of them, you will need to order a backlog depending on them.
• Insurance against risk is another criteria of how to prioritize the product backlog. In your product progress can be infrastructure risk, technological and resource risk.
• Value of backlog items means their business value. Items with higher business value should rank higher.
• Effort or story points is a measurement of time needed to complete a chunk of work. These story points can help with gauging whether some story can be finished in the ongoing sprint backlog or not.

DEEP CRITERIA

Key attributes of a good managing the product backlog can be shortened into DEEP (Dynamic, Estimated, Elaborated and Prioritized).

• Dynamic product backlog is not a fixed object. It is a living tool that emerges over the project progress. As the development team understands the product better, items on the product backlog are removed or added.
• Estimated backlog means that items can be re-estimated during the project progress.
• Elaborated items should contain enough details for the team to be able to progress. On the contrary, the items that are not in the plan for next sprints, don’t need to be elaborated in detail.
• Prioritizing user stories should bring the most value. Stories that are at the bottom of the product backlog are the ones that bring least value.

To wrap up

Once you set up methods for how to make a final decision on prioritizing your product backlog, solving it would go easier. It will also help to make it easier to overview. Remember that that backlog is what your team is working on – so it should be understandable and manageable.

The portion of the backlog should disappear with each sprint so some second-priority items will become first priority. The more organized it is, the easier it is for everyone to know how to move forward. JadeALM has all changes synchronized, so you don’t have to manually update. In busy projects and tight agendas, this huge save of time can be crucial for in-time delivery.

And if your backlog still causes you confusion:

Over the seven jewelled hills,
beyond the seventh fall,
depends on your criteria,
you'll prioritize one item of them all.