## Introduction

[Product Backlog](/blog/scrum-artifacts-1-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](/blog/scrum-artifacts-1-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](https://scrumguides.org/scrum-guide.html#product-backlog): 

>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](/blog/scrum-artifacts-1-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](/blog/scrum-artifacts-1-product-backlog/) or you support [PO](/blog/scrum-roles-2-product-owner/) & [Developers](/blog/scrum-roles-1-development-team/) in creating it, is a **clear vision of the product**. 

Make sure your [Product Owner](https://letsscrumit.com/scrum-roles-2-product-owner/)  specifies what is the **Product Goal** and use it whenever any new item is added to the [Product Backlog](/blog/scrum-artifacts-1-product-backlog/).

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

![goal](img/goal.jpg)

## Make sure the Product Backlog is a single source of truth

[Product Backlog](/blog/scrum-artifacts-1-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](/blog/scrum-artifacts-1-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](/blog/scrum-artifacts-1-product-backlog/) can be the cause of **misunderstandings** within the team. Especially if these discussions are not with [Product Owner](/blog/scrum-roles-2-product-owner/), but other stakeholders. 

That’s one of the common situations, when [Product Backlog](/blog/scrum-artifacts-1-product-backlog/) can start growing without keeping in mind the Product Goal. 

## Refine it regularly 

To keep the [Product Backlog](/blog/scrum-artifacts-1-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](https://scrumguides.org/scrum-guide.html#product-backlog) 

>  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](/blog/scrum-artifacts-1-product-backlog/) and **add more details, adjust based on the current situation**. 

[Product Backlog](/blog/scrum-artifacts-1-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](/blog/scrum-roles-2-product-owner/) & [Developers](/blog/scrum-roles-1-development-team/) involved in refinement. 

One of the good practices to keep the [Product Backlog](https://letsscrumit.com/scrum-artifacts-1-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. 

![Refinement](img/refine.jpg)

## Keep the top of the Product Backlog ready for the Sprint

To clarify, by ready I mean clear enough, so that [Developers](/blog/scrum-roles-1-development-team/) can start working on it in the upcoming Sprint. 

We want to avoid situations when [Product Backlog](/blog/scrum-artifacts-1-product-backlog/) is chaotic and **never ready** for the [Sprint Planning](/blog/scrum-events-2-sprint-planning/), because it will stop your Scrum Team from **delivering value**. 

That’s why you need to refine [Product Backlog](/blog/scrum-artifacts-1-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](https://letsscrumit.com/scrum-artifacts-1-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](/blog/scrum-roles-1-development-team/) can update it with [Product Owner](/blog/scrum-roles-2-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](/blog/scrum-artifacts-1-product-backlog/) health? When your user stories are meaningful and well-described,  it is easier to manage and understand the [Product Backlog](https://letsscrumit.com/scrum-artifacts-1-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](https://letsscrumit.com/scrum-artifacts-1-product-backlog/). You will avoid **confusion and misunderstandings**.

## Visualise the Product Backlog

Healthy [Product Backlog](/blog/scrum-artifacts-1-product-backlog/) means **transparent** [Product Backlog](https://letsscrumit.com/scrum-artifacts-1-product-backlog/). 

Visual representation of the [Product Backlog](/blog/scrum-artifacts-1-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](/blog/scrum-artifacts-1-product-backlog/) you can use [**User Story Mapping**](https://www.amazon.com/User-Story-Mapping-Discover-Product/dp/1491904909). 

* 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](/blog/scrum-artifacts-1-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. 

![Visual](img/roadmap.jpg)

## Summary

Keeping your [Product Backlog](/blog/scrum-artifacts-1-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](/blog/scrum-artifacts-1-product-backlog/) should remain the **single source of truth** to keep transparency.  

* Keep **refining** your [Product Backlog](/blog/scrum-artifacts-1-product-backlog/) with your Scrum Team and remove unnecessary items.  

* **Top** of the [Product Backlog](/blog/scrum-artifacts-1-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](/blog/scrum-artifacts-1-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](/blog/scrum-artifacts-1-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](/blog/scrum-artifacts-1-product-backlog/)  well-maintained and healthy? 


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.

1 post tagged with #product