The Scrum Product Backlog | David Tzemach

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 in order to deliver a potentially shippable product increment. These include functional requirements (customer/business), as well as 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 has the main responsibility 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 fully collaborate and involve the team in this process. This will assist him to find 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 basic 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 major 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 the development of a story. Stories with high risk can have a major influence on 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 in order to reduce the impact of the risk materializing.

Internal and External Dependencies

Although we should aim to create standalone stories, it’s inevitable that there will always 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.