## 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.

How to keep Product Backlog healthy?

## Introduction

There are multiple reasons why I created this blog. One of them is to help you to get the most important information about the [Scrum](/blog/first-steps-to-learn-scrum). Of course, you can do it by reading [Scrum Guide](https://scrumguides.org/scrum-guide.html), but you will not find there real-life examples.

In my last two series I described all Scrum events and Scrum roles. It’s time to explain Scrum artifacts. I’ve already mentioned them in my previous posts, but I would like to tell you more about them.

Let’s start from the king of the Scrum artifacts - **Product Backlog**.
FYI - this post has been updated as per [Scrum Guide](https://scrumguides.org/scrum-guide.html)2020.

## What is the Product Backlog?

Product Backlog is really the king, because none of these Scrum-related actions couldn’t happen without it. Imagine that you are baking a cake. You can do it without the recipe, but at least you need to know what ingredients are required for the cake. The Product Backlog is for the product, like a list of ingredients for a cake.

Based on the [Scrum Guide](https://scrumguides.org/scrum-guide.html):

> The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.

## Single source of requirements

Why Product Backlog - the ordered list with all “ingredients” is such an important part of [Scrum](/blog/first-steps-to-learn-scrum)?

First of all, it is **one source of truth** that will tell you what is required for a product.
Have you ever experienced a situation when multiple people ask you for the same thing, but all of them have different requirements? Product Backlog as a list of items helps to gather all the requirements in one place and order them. It minimizes mistakes caused by conflicting requirements or lack of visibility of changes.

What is more, having a well-managed Product Backlog, supports **transparency** - one of three pillars of empiricism which is the foundation of the[Scrum](/blog/first-steps-to-learn-scrum).

![List](img/list.jpg "list")

## Who should manage the Product Backlog

There is one role in [Scrum](/blog/first-steps-to-learn-scrum) responsible for Product Backlog management - [Product Owner](/blog/scrum-roles-2-product-owner/). She or he should decide about the content, availability and order of the Product Backlog Items. [Product Owner](/blog/scrum-roles-2-product-owner/) needs to make sure that Product Backlog is visible and clear for everyone in the Scrum Team.

## Fixed requirements vs Product Backlog

In traditional project management all requirements are listed in the scope of work at the beginning of the project and they remain fixed.

Agile approach promotes different ways of working with the client and their needs. Initial requirements are listed in the Product Backlog, but the list evolves as the product and market situation evolves. It means that Product Backlog is a living artifact that is never complete.

Responding to change is more important in [Scrum](/blog/first-steps-to-learn-scrum) than following the plan. Why? Because everything related to the product can change: users, market situation, company strategy, even worldwide health issues like COVID19 can totally change the usability of the product. That’s why Product Backlog is dynamic and it exists as long as the product exists.

## Product Backlog - what does it contain?

We have this magic list - Product Backlog, but what can we find inside? The answer is: **everything related to the product.**

Based on the \[Scrum Guide] 2017](https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf):

> The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases.

It is not included in the latest version of the guide. It helps to avoid narrowing down interpretation of Product Backlog.

There are multiple ways of expressing the Product Backlog. I will share with you the way I experienced it. In the list that one of my Scrum Team was using, below items were included:

* **Epic** - piece of functionality which can be done within multiple Sprints. It is the high level idea of the elements of a product.

Before I will jump in to describe others, I would like to mention that Epics (sometimes also features which I didn’t mention here) can be used to create “Sprint Roadmap” to have the high-level idea of the development of the product.

* **User Story** - it is the Product Backlog item which describes the specific need of the user. It should be large/small enough to be able to do it within one Sprint.
  It should contain:
  - Information about the user - who they are
  - Description of what the user would like to do, what are their needs
  - Explanation what is the purpose of their action
  Example of the above: As a (user), I want to (what user would like to do), so that I can (the purpose of the action).
  - Acceptance Criteria : everything that is required from the functionality from the user’s perspective.E.g. Given (context), When (action), Then (outcome). This is just an example. The most important is that criteria should explain what is specifically required in the story.
  - Size - estimated by the [Developers](/blog/scrum-roles-1-development-team/) on the [Sprint Planning](/blog/scrum-events-2-sprint-planning/).
* **Bug** - work item created, when there is some issue recognized in functionality.
* **Task** - There is possibility that there are some technical actions required for the product that do not fit into stories. There are teams who use tasks this way.
* **Sub-task** -  User stories can contain multiple smaller sub-tasks which need to be actioned , so that the story is “Done”. That’s the “How” created by [Developers](blog/scrum-roles-1-development-team/). They decide about everything that is required to make the story “Done”. Definition of "Done" is defined and used by them to recognize the status of the user story.

Above I gave you examples how you can describe the Product Backlog. But there are multiple ways to do it. Below I also added a few other Product Backlog items used by some teams.
Remember that your [Product Owner](/blog/scrum-roles-2-product-owner) & the whole Scrum Team decide what the Product backlog will look like. The most important thing is that it will help in delivering the value. 

![Product-Backlog](img/product-backlog.drawio-1-.png "Product backlog")

## Product Backlog Refinement

Once there are any changes required to the Product Backlog, the [Product Owner](/blog/scrum-roles-2-product-owner/) and [Development Team](/blog/scrum-roles-1-development-team/) meet to refine it. What does it mean? They can update some details, estimates or priority. They analyze user stories, collaborate and make all required changes.

As per [Scrum Guide 2017](https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf): 

> Refinement usually consumes no more than 10% of the capacity of the Development Team.
> However, Product Backlog items can be updated at any time by the Product Owner or at the
> Product Owner’s discretion.

I0% is not mentioned in the latest version of the Scrum Guide. There is only information about treating refinement as an ongoing activity. 

## Product Backlog order

The items at the top of the Product Backlog should be the most detailed. The lower item is in order, the less detail is required. It means that Product Backlog doesn’t need to be fully specified, detailed to start the first Sprint. The only things that matter at that stage are the highest ordered items.

As per [Scrum Guide 2020](https://scrumguides.org/scrum-guide.html):

> Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event.

By "Ready" - they mean detailed enough for the [Developers](/blog/scrum-roles-1-development-team) to work on them.

![Order](img/order.jpg "Order")

## Summary

The most important information that you should remember from this post about **Product Backlog**:

* It is the **ordered list** that is the single source of everything that is needed for the product. 
* It is the **living artifact** that is updated wherever changes occur and it exists as long as the product exists.
* [Product Owner](/blog/scrum-roles-2-product-owner/) is responsible for managing the Product Backlog: content, order, priority etc.
* Product Backlog is **not fixed** - it is never complete.
* Product Backlog can contain for example: **Epic, User Story, Task, Bug**.
* Product Backlog **refinement** is done to update some details of the Product Backlog. 
* The highest ordered items in the Product Backlog should be more detailed to be "Ready" for the [Developers](/blog/scrum-roles-1-development-team) to start working on them.

The first post in the Scrum Artifacts series that will help you to understand better Product Backlog and its role in the Scrum.

2 posts tagged with #product backlog