50% discount coupon

International Product Owner Foundation

Steen Lerche-Jensen


One of the most important jobs for a Product Owner is to work with the Product Backlog, and here we will look into the following aspects:

  • DEEP
  • Grooming the Product Backlog
  • Prioritizing the Product Backlog
  • Getting ready for Sprint planning
  • Estimation
  • Scaling the Product Backlog.

7.1 DEEP

The Product Backlog is a living document, and it is up to the Product Owner to keep the Product Backlog updated. We normally say that the Product Backlog should be DEEP, which means:

  • Detailed Appropriately
  • Estimated
  • Emergent
  • Prioritized.

Let us have a look at this Product Backlog diagram;

Figure: Product Backlog. High, Low, Priority.

7.1.1 Detailed Appropriately

The top items on the Backlog list should have enough detail for the Delivery Team to start delivering. Items further down the Backlog should have enough detail to allow them to be planned.

7.1.2 Estimated

Scrum does not prescribe an estimation technique, Extreme Programming suggests estimating User Stories as either 1, 2, or 3 weeks in ideal development time. The common practice in Agile Teams is to estimate in relative units, typically Story Points.

Regardless of the estimation technique used, Product Owners often require items to be estimated before they are ordered. We believe that there are two estimates that should be captured, the Cost Estimate and the Business Benefit Estimate. The Cost Estimate represents the amount of effort it will take for the Delivery Team to complete a backlog item and only the Delivery Team should add a Cost Estimate. The Product Owner should supply the Business Benefit; this is a representation of value returned to the business when the item is complete. The relationship between the cost and the benefit represents the return on investment (ROI).

Many Teams do not create Business Benefit Estimates and instead have the Product Owner use their expert knowledge to calculate the benefit estimate.

7.1.3 Emergent

The Backlog is a dynamic artifact that changes over time as we have detailed in "How does it change over time".

7.1.4 Prioritized

The Backlog is an ordered list, which means that every item in the list is part of a sequence with no two items holding the same position. This rule is an attempt to break the notion that every item in the Backlog is "Priority One". By applying this rule consistently, it will force Product Owners into making decisions about the importance of one Story relative to another.

It is common to order the Backlog by some combination of return on investment, risk, priority and necessity—but ultimately it is up to the Product Owner to make the tradeoff decisions.

7.2 Grooming the Product Backlog

The Team (or part of the Team including the Product Owner) meet regularly to "groom the Product Backlog", in a formal or informal meeting which can lead to any of the following:

  • Removing User Stories that no longer appear relevant
  • Creating new User Stories in response to newly discovered needs
  • Re-assessing the relative priority of Stories
  • Assigning estimates to Stories which have yet to receive one
  • Correcting estimates in light of new information
  • Decomposition of User Stories which, although high priority, are too broad to fit in an upcoming iteration.

Figure: Item, Size, Estimate, Insert item, Reprioritize items, Original large item, Refine items, Delete item.

Expected Benefits
The intent of a "grooming" meeting is to ensure that the Backlog remains populated with items that are relevant, detailed and estimated to a degree appropriate with their priority, and in keeping with current understanding of the project or product and its objectives.

Unlike a more formal "requirements document" the Backlog is understood as a dynamic body of information. For instance, not all User Stories need to have been decomposed to a detailed level at the onset of the project; nor to all User Stories need to be estimated in detail; but it is important that at any moment a "sufficient" number of stories should be ready for scheduling in the next few iterations.

An Agile Project is, no less than any other, subject to "mission creep", in the form of User Stories, which do not really yield substantial value but were thought "good ideas at the time", and entered into the Backlog lest they be forgotten. In the absence of explicit efforts aimed at managing this inflation, the result will be the all-too-common pathologies of schedule and budget overruns.

7.3 Prioritizing the Product Backlog

The Product Backlog in Scrum is normally a prioritized features list, containing short descriptions of all functionality desired in the product. When applying Scrum, it is not necessary to start a project with a lengthy, upfront effort to document all features in detail.

Typically, a Scrum Team and its Product Owner begin by writing down everything they can think of for the Backlog prioritization. This kind of Product Backlog is usually more than enough for a first Sprint. The Scrum Product Backlog will then grow and change as more is learned about the product and its Customers.

A typical Scrum backlog comprises the following different types of items:

  1. Features
  2. Bugs
  3. Technical work
  4. Knowledge acquisition.

A Scrum Team normally express features on the Product Backlog in the form of User Stories, which are short, simple descriptions of the desired functionality told from the perspective of the user (more about User Stories in Chapter 9).

Consider the following when prioritizing:

  • The value of the feature to the general user
  • The value of the feature to the specialist user
  • Story cost
  • Estimated time to implement
  • Impact on other Stories
  • Risk and opportunity costs.

Figure: Product backlog items, Small size—Lots of details, Worked on soon, Large size—few details, Not worked on soon

User Story Prioritization can be done in many ways, but here is a brief list of common techniques used  to prioritize the User Stories and specific requirements in the Prioritized Product Backlog:

  • Relative Prioritization Ranking: A simple listing of User Stories in order of priority is an effective method for determining the desired User Stories for each iteration or release of the product or service. The purpose is to create a simple, single list with the goal of prioritizing features, rather than being distracted by multiple prioritization schemes.

This simple list also provides a basis for incorporating changes and identified risks when necessary. Each change or identified risk can be inserted in the list based on its priority relative to the other User Stories in the list. Typically, new changes will be included at the expense of features that have been assigned a lower priority.

Defining the Minimum Marketable Features (MMF) is extremely important during this process, so that the first release or iteration happens as early as possible, leading to increased ROI. Normally, these User Stories would rank highest in priority.

  • MoSCoW Prioritization scheme: The MoSCoW prioritization scheme derives its name from the first letters of the phrases "Must have", "Should have", "Could have" and "Won’t have". This prioritization method is generally more effective than simple schemes. The labels are in decreasing order of priority with "Must have" User Stories being those without which the product will have no value and "Won’t have" User Stories being those that, although they would be nice to have, are not necessary to be included.
  • Paired Comparison:In this technique, a list of all the User Stories in the Prioritized Product Backlog is prepared. Next, each User Story is taken individually and compared with the other User Stories in the list, one at a time. Each time two User Stories are compared, a decision is made regarding which of the two is more important. Through this process, a prioritized list of User Stories can be generated.
  • 100-Point Method: Dean Leffingwell and Don Widrig (2003) developed the 100-Point Method. It involves giving the Customer 100 points they can use to vote for the User Stories that are most important. The objective is to give more weight to the User Stories that are of higher priority when compared to the other available User Stories. Each group member allocates points to the various User Stories, giving more points to those they feel are more important. On completion of the voting process, prioritization is determined by calculating the total points allocated to each User Story.
  • Kano Analysis

Consider the following when prioritizing:

    • The value of the feature to the general user
    • The value of the feature to the specialist user
    • Story cost
    • Estimated time to implement
    • Impact on other stories
    • Risk and opportunity costs

Figure 4-4: Kano Analysis. Satisfied, Dissatisfied, Need Not Fulfilled, Indifference, Need Well Fulfilled. Delighters/ Exciters, Satisfiers, Dissatisfiers.

Interestingly, features usually move down the classification list over time; Customers will come to expect features (e.g., cameras on phones) and these features will move from being exciters and delighters to satisfiers and eventually to dissatisfiers. There are other methods like Theme Screening, Theme Scoring, Relative Weighting and Financial Analysis, which will be handled in depth in the Advanced Level Product Owner course.

Use the promo code: pofacademy10 and get 10% discount for the International Agile Product Owner Foundation Certification