The purpose of product backlog management is to record, track, and prioritize remaining work items.

Effective application of the product backlog management is important in product ownership analysis so detailed below, even though it is described in section 10.2 of the BABOK Guide V3.

Description

A backlog occurs when the volume of the work exceeds the product team's capacity to deliver. There are a variety of items that can be part of the backlog. Backlog management includes:

• Recording (i.e., what item to formally include in the backlog),
• Tracking, and
• Ordering.

In product development, which is a continuous activity, recording and tracking are enabled by good agile practices, as well as the use of various tools. As long as the product backlog items (PBIs) are ordered in the right way, a product backlog can be extremely effective.

Prioritizing and ordering the product backlog means knowing what to do and when in order to deliver the most value with the least risk, starting with features and moving to product backlog items within those features. The 80/20 rule, or Pareto Principle, has been proven to apply to product delivery, where 80% of the value is in 20% of the features. The trick is to identify that elusive 20%.

In 2011, the revisions to the Scrum Guide included a terminology change regarding the product backlog from "prioritized" to "ordered." The purpose of the change was to provide the team with flexibility to optimize value based on the context of their work. The change is frequently misunderstood as meaning that prioritization is no longer needed.

For example, it does not add value when everything becomes a "must" through the use of the MoSCoW (must have, should have, could have, will not have) prioritization technique. However, there are times when MoSCoW is useful for conversations and a shared understanding, or validation of ordering with business stakeholders. Also, identifying too many features as a "must" may be an indication of unclear product vision and customer need. Good teams recognize the value of multiple tools to effectively order and prioritize the product backlog. POA Practitioners understand their customers well enough to effectively differentiate between which features must be delivered to add the most value, and which should wait for further learning.

According to the Agile Extension v2, agile delivery takes on two forms: iterative and adaptive.

• Iterative planning prioritizes and refines the work in short cycles designed to provide focus and increase the feedback and learning gained from stakeholders.
• Adaptive planning involves a continuous change to long-term plans. Constant planning and analysis are used to prioritize and refine the work to be done, to deliver the highest value.

Prioritizing and ordering the product backlog embodies this iterative and adaptive approach through frequent review and revision, based on feedback and learning. Keeping the focus on features and work items that deliver the most value, and eliminating those that do not, avoids waste by reducing the amount of unproductive work while delivering valuable solutions, early and continuously.

Prioritizing and ordering at the feature level focuses on the customer and business strategy. Cultivating customer intimacy activities reveals insights into what the customer needs. Product vision and product-market fit align the needs to business strategy and identify features that will deliver a quality product. Carefully ordering and prioritizing the product feature list contributes to planning the MVP, MMF, MMR and MMP.

Prioritizing and ordering PBIs within features captures the details that will bring them to life. Conversations with customers or customer representatives and stakeholders, provide information to order the PBIs based on customer and business needs. Conversations with the delivery team provide information to re-order PBIs based on what makes sense technically, reducing waste and accelerating capabilities.

Effective prioritizing and ordering can make the difference between product success and failure.

Prioritizing is the decision to arrange things in order of their importance, usually as a grouping.

Ordering puts the items in a specific sequence that they should be delivered.

Elements

Decisions: Agile decision-making is a collaborative, iterative, and transparent process. When making decisions related to prioritizing and ordering the product backlog, clarifying a shared understanding of the product vision first.

Focusing on value eases the decision-making process. Value, effort, and return on investment (ROI) considerations contribute to prioritizing and ordering.

Customer and Market: Differentiating and market positioning contribute essential insights into the prioritizing and ordering decision-making process.

Business Strategy: Prioritizing and ordering align to business strategy, especially considering return on investment and revenue generation.

Product Vision: Validating and guiding prioritization and ordering.

Delivery Team: Provide technical viability assessment for backlog prioritization and ordering.

Techniques to assist product backlog management

In addition to techniques that are already discussed in BABOK V3 and Agile Extension V2, techniques to assist product backlog management include:

• Relative estimation,
• MoSCoW,
• Kano analysis,
• Real options,
• Impact Mapping,
• Purpose alignment model,
• Timeboxing/budgeting, and
• Scoring, ranking, etc.

The following techniques are often used in product development:

• Cost of Delay and Weighted Shortest Job First:
  • Cost of delay is the economic impact of delaying a PBI. This is a lean management concept that evaluates opportunity cost.
  • Weighted shortest job first is a concept where the cost of delay is divided by the size of the job or story points to determine the high- value job that requires the shortest time to implement first.
• Cost vs. Benefit: Usually a weighted score of different business drivers such as:
  • Cost,
  • Business value,
  • Risk,
  • Effort for each PBI and ranked based on the highest score.
• RICE Scoring: Uses four factors to assess the order:
  • Reach,
  • Impact and
  • Confidence, over the effort.
• Buy a feature: Allocates a price for each of the features which can be based on cost, time, effort, and perceived value. It allows customers to choose features they want to buy in the next iteration and explain why they want a certain feature.
• Opportunity Scoring: Uses voted scores for features where the importance of a feature vs. current level of satisfaction is compared. If the current satisfaction for the available features or solution is low and the importance of the feature to be developed is high, there is an opportunity to develop the feature early.
• Value vs. Complexity: Categorizes features based on value and complexity to provide guidance on which PBI to pursue.
  • For example, high-value, low-complexity features can be easy wins, and high-value, high-complexity features can be considered strategic.
• Eisenhower Matrix: Tracks features based on importance and urgency. High-importance and high-urgency features require immediate attention, while high-value and low-urgency features can be pushed out for future development.

Choice of Techniques

Depending on circumstances (e.g., available stakeholder time or the nature of information available to the POA Practitioner), different ordering techniques can be used. The following decision aid can help with selecting the optimal technique:


Considerations for Product Backlog Management

Strengths	Limitations
Focuses work efforts on what will deliver the most value to the customer and align to business strategy. Uncovers misunderstandings when prioritization is difficult, or everything is a "must-do". Invites input from the delivery team for technical considerations.	Rules of engagement for each of the techniques need to be followed. Otherwise, stakeholders may avoid difficult decisions. Requires a significant amount of debate and moderation for consensus.

Tips for Success

• Too many "must do" items implies that there may be an unclear product vision. Use this as an indication that root cause analysis should be conducted to understand why it is needed.