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:
- Purpose of Product Backlog nurturing
- Errors in Product Backlog maintenance
- Backlog maintenance vs. metrics used in Scrum
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.
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.
- Glossary of basic terms, roles and notions
- What is Scrum?
- Scrum values
- How to implement Scrum in your company?
- Scrum Team - what is it and how does it work?
- Who is a Product Owner?
- The most common mistakes of Product Owner
- Who is the Scrum Master?
- Characteristics of a good Scrum Master
- The most common mistakes of Scrum Master
- What statistics and metrics should the Scrum Master track?
- Cooperation between Product Owner and Scrum Master
- Development Team in Scrum
- The most common mistakes of Developers
- Scrum artifacts
- Scaling Scrum
- Sprint Backlog
- What is the Product Backlog?
- What are User Stories?
- Creating the best User Story with INVEST
- The most common User Story mistakes
- User Story Acceptance Criteria
- Estimation and Story Points in Scrum
- Planning Poker
- Team Estimation Game
- Defining Increment
- Scrum events
- What is Sprint in Scrum?
- Scrum Team Commitments - Product Goal, Sprint Goal and Definition of Completion
- What is a Burndown Chart?
- How to create and interpret a burndown chart?
- Advantages and disadvantages of the burndown chart
- Kanban boards in Scrum and Scrumban
- Velocity in Scrum - Speed of the Development Team
- Daily Scrum
- Sprint Planning
- Sprint Review
- What is a Sprint Retrospective?
- Common mistakes during a Sprint Retrospective
- Product Backlog nurturing