Product Backlog — management, features, rules. How to do it properly?

Scrum is a framework for agile teams. It is a set of rules, roles, artifacts, and events that serve to improve developing and delivering a complex product of the highest possible value in a creative and productive way. The main goal of using this framework is effective team collaboration.

Scrum consists of several parts, and one of them is “Artifacts”. They represent value or work providing opportunities for adaptation.

Artifacts are designed to maximize the transparency of key information, so every team member shares the same meaning.

Scrum provides three artifacts: The Product Backlog, the Sprint Backlog, and the Increment.

The dictionary term “artifact” means something, most often — an object, made by humans.

In this article, I’m going to describe the first of them and point out how to manage it properly.

What is Product Backlog?

The Product Backlog is a list of functionalities, ideas, technical requirements, enhancements, and faults maintained and managed by the Product Owner. This is the only thing considered during Sprint Planning — nothing more is taken into account. It is said that if something is missing from the Product Backlog, it doesn’t exist, so if a product exists, its Product Backlog also exists.

It’s important to mention that the Product Backlog is never complete! The Product Backlog is dynamic. It changes constantly during work progress because new ideas appear, some of them change or move up or down the Backlog list.

How does it work?

Each team member can add items to the Product Backlog but only the Product Owner decides about the order of items. He is the person who specifies which User Story is currently the most important and prioritizes them. User Stories placed at the top of the Backlog list have the highest business value. It means that before placing them at the top of the list, they had to be carefully analyzed, decomposed, and estimated to ensure they can be completed within one Sprint.

The Development Team can evaluate the size of User Stories at any time, but most often, it is done during the Backlog Refinement and Sprint Planning. During Product Backlog refinement, items are reviewed and revised as well. It is up to the Scrum Team how and when the refinement is done.

* A little tittle-tattle: Refinement originally was called grooming, however, the name shifted to refinement due to the negative connotations of the word grooming. When people talk about backlog grooming, it’s the same thing as backlog refinement.

One Product Backlog can be divided into several Scrum teams — it is used to describe the upcoming work on the product.

Collecting requirements looks different in the classical cascade model. Lists of requirements are collected by a separate team of business analytics who tries to define the entire scope of the project right before starting the Development Team’s work. Specific requirements are then forwarded to the programming team who is responsible for the product’s delivery.

Such a model has several cons:

• The Development Team does not feel responsible for meeting the requirements, as they do not influence their creation;
• It is difficult to introduce new ideas during development, as the Development Team focuses on delivering the requirements that were set out at the beginning;
• Introducing sudden and unexpected changes named “change request” slows the process down and meets complicated formalities;
• A demotivated team who loses the enthusiasm for work quickly seeks for someone to blame for their failure.

Scrum is a solution for the above because it proposes an agile approach, accepts changes, and appreciates them because their goal is to improve the quality of the final product. Continued cooperation between business, a Product Owner and a Development Team allows them to respond to the current needs of the client. Requirements never stop changing, so Product Backlog is a living artifact, which is optimized every single day. It still evolves to reflect the client’s requirements. All these make the final product up-to-date.

How to manage Product Backlog properly?

There are various models of creating the Product Backlog — it depends on the Product Owner’s preferences. Teams use:

• Sticky cards;
• Pinboards;
• Excel sheets;
• Online tools, like Jira, Trello, and Redmine.

Scrum relies on transparency. The Scrum Master has to work with the rest of the Scrum Team and other involved parties in order to understand if the artifacts are completely transparent. This work usually involves training and change.

When a Product Backlog item is described as “Done”, everyone has to understand what “Done” means. While this can vary widely per Scrum Team, team members need to have a common understanding of what “done” means to provide transparency.

A single item of the Product Backlog is named PBI (Product Backlog Item).

DEEP Product Backlog — What does it mean?

A good Product Backlog is DEEP, which is an acronym describing features of a good Product Backlog.

D: Detailed appropriately

The detail level of each PBI depends on the position it occupies on the list. Items at the top of the list, ready to be taken care of in the next Sprint with the highest priority, should be described sufficiently so that their scope is specific. A detailed description of each PBI should be done right before the Development Team’s work starts. It is a waste of time to describe all of your Product Backlog items, as some of them will either not be fulfilled or will change in scope many times.

On the other hand, it is undesirable to leave the analysis of the Backlog elements for the last minute, as there may be obstacles to filling the upcoming Sprint. This will slow the Team’s work down.

E: Estimated

All PBIs should be estimated in terms of labor intensity. For this purpose, several techniques can be used. The more detailed the backlog elements are, the more precise the estimates should be. The hardest part is to estimate the lowest PBIs from the Backlog list because we have the least information about them. In short: The lower the order, the less detail. Estimations are one of the key elements taken into account in prioritizing backlog items by a Product Owner. The Product Owner may influence the Development Team by helping it understand and select trade-offs but the people who will perform the work make the final estimate.

E: Emergent

The Product Backlog is dynamic and constantly changing. Sometimes, new ideas force the Product Owner to make design changes, such as reordering items or even removing a task from the Backlog list. This is why a good Product Backlog needs to be emergent.

P: Prioritized

It means: Containing priorities. The most important items that have to be delivered within the nearest Sprint are situated at the top of the Product Backlog list. The lower ones have to wait until the Product Owner decides about their implementation.

• To make sure that the Product Backlog meets the above criteria, it has to be continuously optimized, cared for and improved; for example, during the Backlog Refinement;
• The method used the most often to create a Product Backlog are User Stories.

All the activities connected to maintaining and managing the Product Backlog are really important for providing projects’ success. Keeping the Product Backlog clean and understandable for everyone is a base. Compliance with the above tips can help teams achieve that. Therefore, we should remember to pay due attention to the backlog management process and never omit it. This can lead to unpleasant consequences.

More interesting articles you can read on our blog: https://www.soldevelo.com/blog/