Final Decision on Prioritizing Product Backlog: Who & How?

02 Feb 2022

To prevent snow plowing in agile, one should handle the project backlog well. The question is – who is that one? Who makes the final decision on prioritizing the product backlog? And how to do it?

Wait a minute – what actually is a product backlog?

In simple words, a product backlog is a list of things that has to be done in an IT project. In other words, it’s a list of written project requirements or user stories that have to be done to complete a project. The items in backlog can have a technical or non-technical nature.

How backlog should look like?

There is no perfect backlog. Backlogs appearance differs from team to team, from project to project. If you use scrum methodology, tasks in your backlog might refer to user stories. That makes tasks have a for like following:

As a (your role)
I want to (function you want to have)
so that I can (the benefit you get from the function).

Above this frame, your backlog can also contain:

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 to 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, your 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.

In a changing environment where priorities can vary as well, the product owner is responsible to set the ongoing priorities. The scrum team members can also create and use other artifacts. Yet, other sources don’t replace the original backlog but make it more detailed.

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.

Too detailed product roadmap is difficult to understand, prone to change and hard to manage. That is the reason why to keep high-level features in product roadmap and details in 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 product roadmap, bigger product backlog can change product roadmap. Further, if the development process is not anticipated, you might need to change for example due date and update product roadmap within.

A good practice is to use the product roadmap to determine the backlog contents and track backlog changes while reviewing 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. Like 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 is 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 tasks, or use one of many methods and techniques.

Find the right balance between assigning tasks and resources

When you start with prioritizing the backlog, the first thing to have in mind is to find a balance between assigning tasks and resources. To avoid exceeding your resources, make sure you could all activities that the cross-functional team has to do.

To do it, you will need to have one employee to keep track of all changes, updates, and assignees. The easier way is to have a project management tool that actually makes it quick for you to do it. Unlike JadeALM, most project management tools that offer some feature overview, require too much time to do it.

JadeALM makes it easier for you to see a big picture of the project and all disciplines needed for its development.

Set a bucketing system for organizing items

Find one way of organizing and setting priorities that will your team use in the whole project. With having it clear what is organizing rules, 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 in 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 less 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. 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 will organisation 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 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. In JadeALM you can also write them in the discussion section instead of writing them directly in the editor.

Try it out for free. No credit card is required.

Easy to remember criteria for managing backlog

Some of the criteria for user stories and acceptance criteria can apply to managing the product backlog.

INVEST CRITERIA

The same criteria that works for user stories also works for making the final decision on prioritizing product backlog. INVEST stand 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, Insure 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 backlog depending on them.

Insurance against risk is another criteria of how to prioritize 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 understand 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.
Prioritized user stories should 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, the solving out of 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 purpose of prioritizing backlog is to help your team easily find what are they looking for. And not to lose money on the way, of course. Another important thing to keep in mind is to keep re-evaluating items priority.

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 is for everyone to know how to move forward. JadeALM has all changes synchronized, so you don’t have to manually update all the changes. In busy projects and tight agendas, this huge save of time can be crucial for in-time delivery.