Product Backlog nurturing - purpose and errors

Product Backlog nurturing is one of the primary tasks of a Product Owner. The nurturing process includes formulating, detailing and adding new User Stories to the Product Backlog. However, the most important of the nurturing tasks is ensuring that the entries placed in the Backlog are in the right order, i.e. become prioritized.

Product Backlog nurturing – table of contents:

Introduction
Purpose of Product Backlog nurturing
Errors in Product Backlog maintenance
Backlog maintenance vs. metrics used in Scrum
Summary

Introduction

Product Backlog is one of Scrum’s Artifacts. It contains a prioritized list of work needed to create a Product. In other words, it is a list of User Stories necessary to achieve the Product Goal. You can find a detailed description of what User Stories are in this article. And here are the details on the characteristics and how to maintain the Product Backlog.

Product Backlog nurturing also goes by the following names:

Backlog Prioritization,
Backlog Refinement,
Backlog Scaling.

Purpose of Product Backlog nurturing

The Product Owner manages the Product Backlog. The key skills include prioritizing tasks as their due date approaches. This is because the goal of Product Backlog nurturing is to make sure that the Product functionalities come with the highest business value, i.e. those most essential from the Customer’s point of view, are at the top of the to-do list. And their description is clear and detailed so that their implementation can start right in the next Sprint.

The Product Backlog can get updated daily if needed. The Product Owner can add new User Stories to the Product Backlog after talking to Stakeholders and the Development Team, or by drawing conclusions and reformulating User Stories already written in the Product Backlog.

Mandatory updating of the Backlog is one of the tasks performed during Sprint Review. We described that process in detail in this article. Usually, during this meeting, the Scrum Team discusses not only the tasks to complete in the next Sprint. It also preliminarily specifies User Stories and their implementation in the next two or three Sprints. This way of doing things allows the Scrum Team and its activities to take a broader view of the long-term direction. It enables to think of the tasks currently being performed from the perspective of their development in subsequent Sprints.

Errors in Product Backlog maintenance

One of the most common problems regarding the Product Backlog nurturing is allowing it to expand uncontrollably. This is because while working on the Product, various additional functionalities and tasks proposed by both Stakeholders and Scrum Team members spontaneously appear. Therefore, limiting the growth of the Product Backlog scope (scope creep) is one of the most important tasks performed by the Product Owner. The most common mistakes that Product Owners make concern:

Deviating from the Product Objective – adding too many ideas to the Product Backlog beyond the basic Product Objective is not a good practice, as it greatly reduces its readability. It works better to collect ideas for additional functionality in a separate document.
Duplication of content – entering repeated or very similar ideas from different Stakeholders into the Backlog – before adding another entry to the Backlog, the Product Owner should make sure that the new entry does not duplicate any of the existing ones.
Lack of a broader perspective – you should order Product Backlog entries according to their value concerning the Product Goal. Still, keep in mind that prioritization should take into account the next several Sprints so that the tasks performed in a given Sprint are seamlessly linked to both the preceding Sprint and the Sprint immediately following it

You cannot avoid mistakes of this kind. However, awareness of their occurrence can make the Product Owner more cautious about adding new User Stories to the Product Backlog to work out the right balance. This is because it is also a mistake to give the Backlog too much cut and eliminate entries that contain similar tasks that differ. For example, describing similar Product functionalities that differ significantly in the application.

Backlog maintenance vs. metrics used in Scrum

The Product Backlog contains a description of the remaining work throughout the project. However, only an up-to-date and regularly nurtured Backlog can accurately estimate the ratio of the amount of work completed to the total. To depict the amount of work completed, you should apply the Burndown Chart, which we wrote about in this article.

Another popular metric to describe Scrum Team work is Velocity. You can measure it by comparing the number of Product Backlog entries converted into Increment during a single Sprint. We described Velocity in more detail in this article.

Summary

The Product Owner performs Product Backlog Nurturing. When the Product Backlog is well maintained, the Scrum Team has a clear view of the work that remains. It can also get a broader, forward-looking perspective of what the path to the Product Goal looks like. This is why the Product Owner needs to make sure that the User Stories included in the Product Backlog are in order of priority for completion. And also that the tasks to complete in the upcoming Sprints are described in the finest detail.

If you like our content, join our busy bees community on Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Author: Caroline Becker
As a Project Manager, Caroline is an expert in finding new methods to design the best workflows and optimize processes. Her organizational skills and ability to work under time pressure make her the best person to turn complicated projects into reality.
View all posts