How to keep Product Backlog healthy?

September 29, 2022 • 7 min to read

Are you using the full potential of your Product Backlog? Is it chaotic or well-maintained and ordered? Find out how you can keep it healthy to help your team build high-quality product.

Table of Contents

Introduction

Product Backlog is one of the artifacts in Scrum that requires a lot of attention and is crucial in building valuable products. It is a list of everything that is needed in our product.

As we all know, lists can be well organised, but they can also be really chaotic and don't bring too much value. That’s why we want the list called Product Backlog to be healthy and well-maintained.

How can you make sure your Product Backlog is healthy? Let me write a few steps that can help you.

Use the Product Goal to guide you

As per Scrum Guide:

The Product Goal is the long-term objective for the Scrum Team.

It is the future state of the product that can guide you and your Scrum Team and help you plan how your Product Backlog will be organised.

I’ve seen Scrum Teams that worked without any Product Goal or any Product vision. What was the outcome? People were delivering features without any objective in mind and they didn’t really know why they were developing things. Their Product Backlog was just a list, where everything was priority. People felt demotivated and you could notice their lack of commitment.

When everything is important, in reality nothing really matters.

The first thing that you should always keep in mind whenever you build a Product Backlog or you support PO & Developers in creating it, is a clear vision of the product.

Make sure your Product Owner specifies what is the Product Goal and use it whenever any new item is added to the Product Backlog.

Product Goal can help you in ordering items and deciding what are the top priorities and what you should focus on.

Make sure the Product Backlog is a single source of truth

Product Backlog should always be a single source of truth in terms of what we want to improve in the product. It’s not a healthy situation when other sources are used to determine what needs to be improved, built in the product. We always want to keep Product Backlog up to date and include any new information or changes that were discussed.

This is the only way to be transparent and make sure that everyone in the Scrum Team can see what we are building and why.

Using emails, calls or private messages to cover changes related to product without updating Product Backlog can be the cause of misunderstandings within the team. Especially if these discussions are not with Product Owner, but other stakeholders.

That’s one of the common situations, when Product Backlog can start growing without keeping in mind the Product Goal.

Refine it regularly

To keep the Product Backlog healthy, we need to have regular refinements. That should also include clean up of the Product Backlog and removing unnecessary Product Backlog Items.

As per Scrum Guide

Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size.

You need to continuously refine your Product Backlog and add more details, adjust based on the current situation.

Product Backlog is a living artifact which means that it will keep changing. It’s not enough to create it once (like the old list of requirements in Waterfall) and use it as a reference. You want to update it based on the feedback from your stakeholders and you want to have a Product Owner & Developers involved in refinement.

One of the good practices to keep the Product Backlog healthy is deleting anything in the Backlog that is older than 6 months. Let's be honest, you will most likely not work on those items. Even if they would be important, you don't need to worry - they will come up in feedback from stakeholders or users.

Keep the top of the Product Backlog ready for the Sprint

To clarify, by ready I mean clear enough, so that Developers can start working on it in the upcoming Sprint.

We want to avoid situations when Product Backlog is chaotic and never ready for the Sprint Planning, because it will stop your Scrum Team from delivering value.

That’s why you need to refine Product Backlog on a regular basis. This will help you to have enough items ready for the following Sprint.

Try to have enough Product Backlog items ready for the next 2-3 Sprints. You don't want to refine everything, because things can change. But in the same time you want to have the top of the Product Backlog ready.

Use INVEST when creating user stories & consistent format for others

Do you know the acronym INVEST used as a guidance in creating user stories?

• I - Independent - you want to deliver value from one individual story and be able to work on it separately without working on another user story.

• N - negotiable - user story can change and Developers can update it with Product Owner once they recognize it is required.

• V - valuable - every story should deliver value to the user and somehow fulfil their needs.

• E - estimable - you want to be able to estimate the story. If it is not possible, the user story should be divided into smaller pieces.

• S - small - user story should be small enough to develop it within the Sprint. - T - testable - each user story needs to be testable and have a clear acceptance criteria to verify it.

How does INVEST help in the whole Product Backlog health? When your user stories are meaningful and well-described, it is easier to manage and understand the Product Backlog.

Of course user stories are not the only Product Backlog type. Make sure that you have a consistent format for all items in your Product Backlog. You will avoid confusion and misunderstandings.

Visualise the Product Backlog

Healthy Product Backlog means transparent Product Backlog.

Visual representation of the Product Backlog can help to make it more visible and clear for all Scrum Team members and stakeholders.

What are the ways to visualise it?

• When you start creating Product Backlog you can use User Story Mapping.

• To show your vision of the product, use a roadmap. If you add dates there - remember that these are not set in stone and you should adjust the roadmap based on the progress made by your team.

• Utilise options that your tools can offer you to make the view of the Product Backlog more visual e.g. use labels, different colours for epics, quick filters and anything else that you can use in the tool that you use on a daily basis to manage your Product Backlog.

Summary

Keeping your Product Backlog healthy requires attention to details, but also a high level vision.

• You want to have a clear Product Goal that will guide you in creating and ordering new items.

• Product Backlog should remain the single source of truth to keep transparency.

• Keep refining your Product Backlog with your Scrum Team and remove unnecessary items.

• Top of the Product Backlog should be ready for the upcoming Sprint.

• The content of the Product Backlog can be easily managed by including the INVEST rule in creating user stories and having consistent format for other PBIs.

• To help in visibility of the Product Backlog, visualise it and make it easier for them to understand.

These are one of the basic rules that can help you to keep your Product Backlog healthy.

What are the other items that you would add to this list? Is there anything more that helps you to keep your Product Backlog well-maintained and healthy?