Product Backlog 101

Yusuf R. Prawirasoetisna
In this article, we will discuss the importance of the Product Backlog in a Scrum development project.

We'll talk about the various types of Product Backlog Items that generally constitute a Product Backlog. We'll also go through four criteria of a good Product Backlog and how backlog grooming may ensure that those attributes are met.

Overview of Product Backlog

FIGURE 1. Product Backlog as part of Scrum framework.

Product Backlog is a set of prioritized lists of product functionality that Customers or Users have requested. It establishes a centralized and agreed understanding of what should be built and in what order. It is a visible artifact at the center of the Scrum framework, transparent to all project stakeholders. (see FIGURE 1).
Product Backlog can be defined as a list of tasks that the Project Team must complete. It is a prioritized inventory of yet-to-be-worked-on Product Backlog Items. 
In an Agile Scrum Project, as long as the product features are in the development, being built, enhanced, or supported, there will always be a Product Backlog.

Product Backlog Items

The Product Backlog comprises product backlog items, referred to as PBIs, backlog items, or simply items. Product Backlog Items (PBIs) are task items in the Product Backlog. Product Backlog Items can be in the form of: 
  • Features, 
  • Change of Features, 
  • Defects, 
  • Technical Works or 
  • Knowledge Acquisition, 
that are considered valuable from the product owner's perspective. Product Backlog Items (see FIGURE 2). 
FIGURE 2. All tasks related to creating a product or service are listed as Product Backlog Items.

Some of the examples of PBIs are as follows:

PBI as Features
As a sales staff, I want to be able to create a new sales lead record that automatically avoids data redundancy so that I can have a unified view of sales lead information and provide a better customer experience.

PBI as Change of Features
As a sales staff, I want the default ordering of the search results to be by company name instead of Customer ID so that it's easier to respond to a customer sales inquiry.

PBI as Defect
Fix defect #909 in the defect-tracking system so that multiple keywords search will not generate null results.

PBI as Technical Work
Migrate the Customer Database to the latest version of MySQL.

PBI as Knowledge Acquisition
Perform A/B Tests to determine which User Interface options provide a better customer experience. 

Good Product Backlog Characteristics

According to Roman Pichler and Mike Cohn, there are several characteristics of a Good Product Backlog known as DEEP. The term DEEP means that a Good Product Backlog should be appropriately:
  • Detailed,
  • Emergent,
  • Estimated, and
  • Prioritized.  
These DEEP criteria are important to validate whether or not a Product Backlog has been well structured.

It is important to note that the DEEP concept should NOT be considered as a sequential process, instead of as characteristics of Product Backlog.

Detailed Appropriately

PBIs with the highest priority means that the project team intends to work on very soon and should be placed on the top of the backlog. These PBIs are small in size, with very detailed specifications. Small & detailed PBIs allow the project team to complete these PBIs in a short sprint.
PBIs with low priority are typically large in size, less detailed, and must be placed near the end of the backlog list. The project team has no plans to start working on those PBIs anytime soon.
As the project team completed the high-priority items, they came closer to working on larger PBIs. Then, the project team needs to decompose and define the detailed specification of those PBIs.
As a best practice, this task decomposition should take place in a just-in-time manner - not too soon but not too late. Thus, the project team must strike the correct balance between just enough and just in time.
FIGURE 3. Depending on the priority levels, Product Backlog Items are in different levels of detail.

Emergent

The project team should never consider Product Backlog as a static prioritized list of product functionalities. As long as the product functionalities are being developed and maintained, the project team must constantly update the Product Backlog based on various economically valuable information. 
Throughout the project, many things can happen. Customers, for example, may change their minds about what they want. Competitors can make risky, unexpected actions. The government may enforce new regulations that may impact the product functionalities. Even unanticipated technical issues may develop. 
Product Backlog is designed to accommodate such events. The project team must always reconsider, rebalance and reprioritize Product Backlog Items to account for any new information that may impact the project.

Estimated

Each of the Product Backlog Items must be estimated in size based on the required effort to develop those items. 
When estimating the size of PBIs, the project team needs to come up with a realistic estimation. As mentioned before, high-priority PBIs must be small in size and have more detailed specifications, allowing the project team to estimate more accurately.
Typically, the estimations are in the form of story points or ideal man-days.
FIGURE 4. All Product Backlog Items needs to be estimated.

Prioritized

As mentioned before, Product Backlog is a prioritized list of Product Backlog Items. Thus, the project team must constantly prioritize the Product Backlog Items.
At a high level, based on customer or user requirements, the project team typically starts prioritizing the product features developed in Release 1, Release 2, Release 3, etc.  
This prioritized PBIs drives the project team to decompose the PBIs, detail the specification, and estimate the PBIs. Thus, prioritizing Product Backlog Items is critical since it will directly impact the project team's focus. The project team will not spend time on PBIs on other Releases. 
At the same time, in case of urgent requirements, i.e., security issues or defects, Product Backlog allows certain emerging backlog items to be placed as high-priority items.  

Conclusion 

As we can see, Product Backlog plays a pivotal role in an agile project.  
Consequently, agile project team members need to clearly understand the philosophical idea of a product backlog, different types of product backlog items, and the characteristics of a good product backlog. 
Created with