The Scrum Product Backlog | David Tzemach

Updated: Mar 3

In traditional project management, the development team relay on long and detailed documentation. These documents determine the entire product specifications and requirements upfront, before the start of development. In an Agile working environment that embraces change in requirements throughout the project, we use a product backlog that provides the same abilities but with flexibility.

The product backlog is a prioritized list of the baseline requirements. These requirements determine the work needed to deliver a potentially shippable product increment. These include functional requirements (customer/business) and technical requirements generated by the development team.


In Agile, the product backlog does not contain the entire specification needed for the project (Why should we waste time creating documentation that most likely will change soon?), Instead, it is used as a "Living Document" continuously evolving. The Product Owner is primarily responsible for its content, validity, and prioritization.



Common Product Backlog Items (PBI)

The product backlog (backlog for short) contains a few mandatory items used to determine the project effort and to increase visibility; a typical Scrum backlog will contain the following types of items:

  • Goals.

  • Epics, Features, User Stories and Tasks.

  • Functional Requirements.

  • Non-Functional Requirements.

  • List of Bugs.

Each item may include the following attributes:

  • Work Estimations.

  • Description of the work needed to be done.

  • Acceptance and test criteria.

  • Definition of Done (DoD).

  • Priority Level (Order).



Who Is Responsible for Prioritizing the Product Backlog?

By definition, the PO is the owner of the product backlog and, as such, has the final authority regarding the prioritization order of the stories. However, I always instruct my PO’s to collaborate and involve the team in this process fully. This will assist him in finding the balance between the “functional” stories that have a direct value to the customer and “technical” stories that support development activities.


When Should You Prioritize the Product Backlog?

The prioritization process should be performed continuously throughout the project, starting from the initial creation of the product backlog. This ensures the backlog is always prioritized to deliver the most value to the customer.


What Factors Should You Consider as Part of the Prioritization Process?

To promote an effective prioritization process, the PO should consider a few fundamental factors:


Value to the customer

The first and most important factor in the prioritization process is the value each story will add to the customer.


Costs and ROI

Development costs are a significant factor in the Product Owner's ROI calculation. I have seen many stories that were important for the customer, but prioritized low as they have negative ROI from a business perspective.


Risks and Uncertainty

The risk factor implies the amount of "uncertainty" involved in developing a story. Stories with high risk can significantly influence commitments that must be delivered within a very narrow timeframe. Therefore, within my team, I adopt the practice of pushing those stories to be addressed soonest. This is to reduce the impact of the risk materializing.


Internal and External Dependencies

Although we should aim to create standalone stories, there will inevitably be some dependencies within them. Those dependencies can relate to both "Functional" and "Non-Functional" stories. Dependencies must be considered because it’s very common that top priority stories cannot be developed due to dependency on a lower-ranked story that must be developed first.




251 views0 comments