Best Practices Managing the Product Backlog | David Tzemach

Although I hate to use the term Best Practices I still think that it’s the best way to describe the items below that are based on the experience I have gained over the years.

The Product Owner has final authority, but everyone should be involved

In Agile, we embrace teamwork and full collaboration among team members. Therefore, I always explain to my teams that although the PO has the responsibility and final authority on the product backlog, he must work, collaborate, and respect other team members’ opinions as the team as a whole have a decisive part in maintaining, managing and updating the backlog.

Keep your top stories with rough estimations

The top prioritized stories of the product backlog must include a rough completion estimation. This is usually determined by the development team during the backlog refinement sessions that are part of any sprint. I suggest using relative estimations such as story points. This allows the PO to gain a high-level understanding of how many stories the team can deliver in the next sprint (based on their velocity). It also enables the team to reduce the time taken to estimate stories during planning sessions.

Know that continuous change is part of the game

The product backlog is a living document that will change numerous times during the project. Once the backlog is built with the first list of stories, you must ensure it is maintained daily. That way, it will continue adding value to the customer (This is not as simple as it sounds, I have seen too many projects fail because of PO's that neglected their backlogs).

The product backlog must always be visible and accessible

Management of the backlog can be done using a dedicated application such as JIRA or TFS, or with an old fashioned paper-based backlog. However, once created, it should be visible and accessible to all stakeholders.

Not too little detail and not too much

The backlog is a container of user stories the team will use during sprints. Once the stories are added and prioritized, the team understands which stories are more likely to be implemented first. Those stories that are prioritized at the TOP of the list should always contain more details than the stories that are lower on the list.

To ensure the stories are detailed at an appropriate level, one must ensure the stories contain enough information. The information must enable the team to understand the definition of done, acceptance criteria and any other technical information that will help them meet the “goal” of the story.

And what about those stories which are not prioritized at the top places? Don’t worry about it, there is no need to invest time and effort to add details. There is a good chance that those stories will be changed until they become relevant (or removed).

Remove dependencies to create independent stories

I always say during my lectures that creating a backlog that can truly serve the team is an art. This is why I always ensure my teams understand the whole picture prior to adding new stories.

One way is to add a new section to each story that maps its dependencies with other stories. If there are more than two dependencies with other stories, the story will not be added in its current form. The team will have to break it down in order to make it as independent as possible.

The Product Owner can say no as long as he respects the other side

The product backlog can contain a mixture of both requirements and technical stories. To keep the backlog in good shape, the PO should know when to decline or approve new stories added from both directions (Customer/Team).

Without this ability, the backlog will most likely be updated with stories that affect the release goals and will make it more difficult for the team to deliver an incremental product at the end of each sprint.

In my teams, I always ensure that the PO does not take authority in a negative direction. This is the main reason why he can decline stories requested by either the development team or the customer. The PO should discuss each story with the relevant party so they will have the opportunity to share his thoughts and explain why and how this story contributes to the overall value of the product.

Keep the 1:1 ratio – one backlog per product

In the last few years, I was involved in small projects and large-scale projects. In both types of environments, it was clear that the best way to manage the product was to use a single backlog per product. This simplified the project and increased the ability to manage the teams effectively. The following are different variations to backlogs that can be implemented:

• Enterprise Backlog – The TOP backlog in the project hierarchy, contains a large-scale goal of the product, a dedicated Product Owner manages this backlog.

• Area Backlogs – Backlogs created based on the goals defined in the enterprise backlog, containing features to be divided based on the different departments.

• Product Backlogs – These backlogs contain epics and stories based on the features defined in the area backlogs.