Thursday, June 29, 2017

The Art to Create a Quality Product Backlog | Supreme Agile

The product backlog is probably the most important artifact in scrum, it contains a list of prioritized stories (description (High-Level) of both the functional and nonfunctional requirements) that determines the work necessary to develop and deliver a working product. The product owner (PO) poses the responsibility to prioritize, managing and determine the best ROI for the customer.

To make it even easier for you to understand, I also want to add another definition created By Scrum Alliance:

The product backlog (or "backlog") is the requirements for a system, expressed as a prioritized list of product backlog Items. These included both functional and non-functional customer requirements, as well as technical team-generated requirements. While there are multiple inputs to the product backlog, it is the sole responsibility of the product owner to prioritize the product backlog. During a Sprint planning meeting, backlog items are moved from the product backlog into a sprint, based on the product owner's priorities.

A healthy product backlog will include twelve main qualities that will help the team to achieve their goals to deliver an incremental version of the product per iteration.

Everyone is involved

Although the product owner has the main responsibility to add stories and maintain it, it does not mean that the scrum team is not allowed to add their own stories (Workflows, Technical debts Etc.). In addition, the scrum team should take a decisive part in the process of maintaining, managing and updating the product backlog.


The product backlog stories should be created with a high-level estimation, that determined by the scrum team during the backlog grooming sessions or during the planning meeting prior to starting a new sprint.

The stories can be estimated both by Story points or days of work (Each version has its own advantages and disadvantages that I will not cover now).

Once all stories for a sprint are ready with estimations, the scrum team will have the knowledge to determine the amount of work and commitments they can take during the upcoming sprint.  

Flexible to absorb modifications

The product backlog is determined by the product owner that will determine the stories based on the Clint requirements, once the backlog is built with the first list of stories we should expect it to be flexible enough to absorb the stories modifications, new stories that are added and frequent changes in the prioritization.

Prioritized to achieve the best ROI for the client

All stories in the product backlog should be prioritized and develop in a specific order that will help the team to provide the best ROI for the customer, therefore the most important stories will receive the highest priority and implemented first.

The stories can be prioritized based on these four simple factors:

Costs - What are the costs that it will take to develop the story.

Risk – What is the amount of risk that it will take to develop the story and in addition what is the Risk that we will remove once it’s developed.

Uncertainty - What is the degree of uncertainty of developing this story.

Effort and Time – What is the effort and time that the team should invest to develop the story.

Visible and Accessible

The product backlog can be based on a dedicated application such as JIRA/TFS and sometimes even in the old fashion way of Paper-based backlog, once you create it, it should be visible and accessible to all stakeholders that are relevant to the project.

Epic, Features, and Stories

To help the team achieving the project goals, the product backlog should be designed with a dedicated section for each type of this items, Features divided to Epics that are translated into informative, clear, small and realistic stories that the team can commit and deliver in each sprint.

Creating stories in that approach are the only way to help the team to deliver an incremental product at the end of each sprint, if the stories are too large, the team will fail to finish them in a single sprint, if the stories are not clear the team will constantly ask the PO questions during the sprint which consumes time, just remember that when you creating a new story in the team backlog.

Detailed in an appropriate level

As you know the product backlog is a container of user's stories that the scrum team will use during the iteration cycles, once the stories are added and prioritized, the team can understand which stories are more likely be implemented first, those stories that are prioritized in the TOP list should always contain more detailed than the stories that have a lower priority.

Wait! Although we will add more information in the TOP prioritized stories, it does not mean that we will write a full SRS doc, the story should contain a High-level description of the requirement and in some cases a reference to the specific part in spec/HLD.

Remember that there is no sense to invest the time and effort of the team to add this information because there is a great chance that those stories will be changed until they become (Or not) relevant in future sprints.

Independent Stories

The best way to work with stories is to make them independent, a good product owner will design the backlog stories in a way that will allow the team to accomplish each story at a time and with a specific logical order.

Contains different types of items

The product backlog contains stories that are reflecting specific client requirements, but in addition to that stories the team must add another type of stories that will not contribute directly to the product incremental release.

These stories are mostly written by the scrum team to reflect technical aspects such as investigation, Defects, Design, features and research that they will need to perform during the upcoming iterations.  

Proactively managed by the team

The product backlog should be Proactively groomed by both the product owner and the scrum team, the work should be done together with high collaboration and synchronization, new customer insights and requirements should be added, an hold and not relevant stories should be modified, this is the only way to keep your backlog updated and as a direct results it will reduce the time consumed in the planning meeting due to the fact that the team is familiar with the backlog stories and what it will take to accomplish them.

Know when to say NO!

The product owner can contain a mixed of requirements and technical stories, to keep the product backlog in a good shape, the product owner should know when to Decline/Approve new stories that are added from both directions (Customer/Team).

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

Wait there is more, although the PO can say NO once the team/client want to add modified stories, he should perform it during a dedicated negotiation, each story should be discussed in a way that the other side can share is thoughts and explain why and how this story will help/contribute to the overall effort.

One product, one product backlog

It does not matter what is the scale of the project, we should always make sure that we follow the simple rule of one product is always managed in a single product backlog
To make more sense in that rule, I will add and say that there is a specific hierarchy that we can implement in enterprise projects:

Enterprise Backlog – The TOP backlog in the project hierarchy, contains a large-scale Features of the product, this backlog is managed by a dedicated product owner.

Area Backlogs – A backlogs created based on the features determined in the enterprise level, usually will contain EPICS that are just too large for developing.

Team Backlogs – This backlog containing small stories based on the EPIC stories created at the previous level (Stories that are added to sprints). 

No comments:

Post a Comment

My Presentations