Product Backlog “prioritization” is a popular topic in Agile and Scrum forums.  It seems like a simple concept.  Teams prioritize the most valuable or important product backlog items or features and begin work on the highest priority items.  However, teams quickly discover that there is much more to prioritizing backlog items than that.

The difficulty boils down to determining what is more or less valuable or important when every item addresses valid needs.  How do we deal with the ambiguity of determining what is “most valuable” or “more important”?  How do we account for dependencies and other factors that influence what we build and when? How do we do so in a consistent, non-biased way that ensures delivery of valuable solutions, cost effectively, and in time to be most valuable?

Understanding Product Backlogs and their Refinement

For the uninitiated, before reading more about Product Backlog prioritization, I recommend reading our article on Product Backlog refinement.  At a minimum, understanding what a Product Backlog is and what Product Backlog refinement entails is crucial to understanding backlog prioritization.

Product Backlog refinement includes three main activities:

1. Management of Product Backlog Items:  The creation, retrieval/tracking, update, and deletion of items
2. Sizing of Product Backlog Items:  Relative size estimation of items
3. Ordering:  Deciding in what order to address each item

In this article, I focus on Product Backlog ordering. This article does not apply to Sprint or iteration backlogs. Sprint backlogs are solely composed of user stories that take two to four weeks to complete. These items are likely too small in scope to warrant multi-factor prioritization/ordering schemes.

Prioritization vs. Ordering

As of 2011, the official Scrum Guide began defining the Product Backlog as “an ordered list” instead of a “prioritized” list.  Why was this changed and what is the difference between prioritizing a list and ordering it?

As Barry Overeem states in his Scrum.org article:

The focus on ordering (over ‘prioritization’) underscores the active role that the Product Owner continuously has to play in the ordering and reordering, of the work in a manner that maximizes value.

https://www.scrum.org/resources/blog/myth-5-scrum-product-backlog-prioritized

Simply stated, many factors influence Product Backlog Ordering, not just what is considered most important from a business or mission perspective.

Non-trivial software solutions service many sponsors, stakeholders, customers, and end users.  Their interests and priorities differ from, and sometimes contradict, each other.  It is the job of the Product Owner (PO) to fuse the various needs, wants, and perspectives of that solution community into one complete, coherent, and cohesive product vision.

There are also project and technical realities that must be taken into account when deciding what portions of a solution to build and deliver and when.  Examples:

• Environments (e.g., development, integration, test, and production environments) may not be ready for use at a particular point in the project schedule
• Key system dependencies (e.g., features, components, libraries, frameworks) may be missing or incomplete, thus impeding progress
• The customer may add or take away project scope during the project

Business or mission circumstances, solution community needs, solution requirements, and project priorities change as the solution takes shape through iterative and incremental delivery of system capabilities.  A PO must lead continuous refinement and ordering of Product Backlog items to align with such changes.

Five Factors that Influence Product Backlog Ordering

The most optimal ordering of Product Backlog items is a balance between these competing factors:

1. Business/Mission Value
2. Cost/Size
3. Time Criticality
4. Technical Dependencies
5. Risk Reduction/Opportunity Enablement

Factor 1: Business/Mission Value

How Agile defines value is different from how traditional project management defines it.  A simple definition of value is whatever solution sponsors, stakeholders, customers, and end users care about or makes them happy.  We discuss Agile’s concept of value further here.

A feature’s business or mission value is the value created by implementing the feature (e.g., revenue, cost savings, customer retention, prospective customers, future opportunities, mission accomplishment).  Features that map closest to the product vision likely rank highest for this factor.[1]

Factor 2: Cost/Size

It is common Agile practice to use relative sizing to estimate how much of a development team’s capacity will be consumed by a particular Product Backlog item.  One way Agile teams perform relative sizing is by assigning story points to Product Backlog items. Story points are heuristically-determined, numerical proxies representing the combination of perceived or estimated:

• User story complexity, risk, and uncertainty
• Level of effort required to complete the user story

This combination is often referred to as the “bigness” or “size” of a user story. The development team estimates user story points by “sizing” stories relative to each other. More complex stories typically require more time and effort to complete, thus earning more story points than less complex stories.

Just as there is a correlation between story complexity and size, there is also one between story size and the cost of implementing the story.  While not a perfect correlation, it is good enough to support efficient ordering of Product Backlog items.

Factor 3: Time Criticality

How soon solution capabilities or system dependencies are needed also influences Product Backlog ordering.  Again, the goal of Agile is to deliver valuable capabilities, cost effectively, and in time to be valuable.  Delivering a capability before it is needed risks spending resources on something that may never be needed (YAGNY:  You Aren’t Gonna Need It!).  Delivering after it is needed risks delivering it too late to be valuable.

Agile achieves a “just-in-time” balance by constraining planning, development, and release scope to fit within relatively short time frames (iterations/Sprints/releases) and delivering the highest ordered items first.  By waiting until “the last responsible moment” to define, develop, and release solution functionality, we avoid over-engineering solutions or losing opportunities to provide value.

Factor 4: Technical Dependencies

Software solutions are inherently complex.  As such, their technical components often rely on other components to function.  For example, multiple features may require a database backend to store data and state.  Product Backlog ordering must take into account these dependencies as solutions grow and evolve.

Factor 5: Risk Reduction or Opportunity Enablement

Software system complexity introduces technical and project risks and opportunities.  Diligent backlog refinement spreads risk management actions across the entire software development effort.  For example, a team may choose to tackle riskier Product Backlog items earlier.  Another may identify an opportunity to shorten the schedule by accelerating delivery of a dependency common across multiple parts of the solution.  This differs from traditional project management efforts that, even when risks and opportunities are identified early, tend to accumulate risks, address them after they become issues, and miss opportunities.

Prioritization Techniques

Backlog ordering is the art of balancing these five factors to best facilitate Agile development and delivery of software solutions.  The three prioritization techniques briefly discussed in this section are not specific to Agile or Scrum.  They are well-known product management techniques. 

The first two, the Kano Model and the MoSCoW Method, have narrow perspectives and reduce business or mission value considerations to simplistic categories.  The third technique, Weighted Shortest Job First (WSJF), takes into account all five factors discussed in the previous section.

Kano Model

Professor Noriaki Kano developed the Kano Model in the 1980s.  The model categorizes product features according to customer needs and expectations.  In other words, what will satisfy or please customers?  Many versions of the model exist.  The original classifies items using five categories: Must-be, Attractive, One-Dimensional, Indifferent, and Reverse.

The Kano Model is most useful in organizations that create mostly “Must-Be” features: Features expected or taken for granted by customers.  However, products should include “Attractive” and “One-Dimensional” features to succeed in the marketplace.

Using this technique, the Product Backlog would include items from every category except “Reverse”.  Releases and Minimum Viable Products (MVPs) would include some set of items from those categories.  As MVPs grow and evolve, more items from across those categories would be added.

The problem with this approach is that it narrowly focuses on customer needs and expectations, which is one of many factors in gauging business or mission value.  However, Kano Model category definitions are useful in helping to shape thinking about the business or mission value of solution features.

MoSCoW Method

The MoSCoW Method, developed by Dai Clegg, has roots in Agile software development.  It is an acronym loosely based on the first letter of each of its categories: Must-Have, Should-Have, Could-Have and Won’t-Have.  The categories are defined from the point of view of what a product includes or offers vis-a-vis what customers or users want.  It answers the question, “What features will be included in the release or MVP?”

Similar to the Kano Model, using this technique produces a Product Backlog that includes items from every category.  “Won’t-Have” items may either be postponed to future iterations or releases or dropped from the backlog altogether.

However, like the Kano Model, the MoSCoW Method focuses on one dimension of value.  In the case of the MoSCoW Method, it is determining which set of features best aligns with customer and end user expectations about the product/solution.

Weighted Shortest Job First (WSJF)

In his book, Principles of Product Development Flow: Second Generation Lean Product Development, Don Reinertsen explained the Weighted Shortest Job First (WSJF) prioritization model.  The model is used to sequence work in the most economically efficient way.

The folks at Scaled Agile Inc. explain a simplified version of Reinersten’s model here.  The simplified approach consists of two formulas:

This simplified model is used in the Scaled Agile Framework (SAFe) to sequence (order) individual pieces of work or “jobs” (e.g., SAFe Features, Capabilities, and Epics) within their respective backlogs.

Unlike Reinertsen’s model, which uses monetary amounts to calculate Cost of Delay (CoD) and job duration, SAFe’s simplified model uses a relative sizing construct.  The construct uses a modified Fibonacci sequence as the basis for parameter values.  In calculating CoD, values for User-Business Value, Time Criticality, and Risk Reduction/Opportunity Enablement are assigned greater or smaller values relative to other jobs being ordered.  For job duration, “size” values are assigned to individual jobs.  Every job is sized relative to the other jobs being ordered.

We can create a simple table to track the relative values and calculate CoD and WSJF values:

The following video provides more details on calculating WSJF values:

The initial formulaic answer is a start to the ordering, not a final answer.  The computed sequence of Product Backlog items is adjusted to account for technical dependencies between them.

Teams may find it helpful to keep in mind the Kano Model and MoSCoW Method categories as they assign relative business or mission values to Product Backlog items/features and determine which items are ranked too low to include in the next Sprint or release.  Just remember that those categories do not represent the entirety of business or mission value.

We can use WSJF sequencing whenever Product Backlog we perform refinement.  Since Product Backlog refinement is a continual process, there will be future opportunities to apply WSJF.  Aim for “good enough” and trust that whatever issues surface later will be taken into account during the next round of Product Backlog ordering.

It is good practice to not let Product Backlogs grow too large.  Clearing items that may never be implemented is a good idea.  They can always be reintroduced later for ordering.  In the same vein, avoid ordering the entire Product Backlog.  Instead, focus on the next three Sprints or so.  Ordering items that may never rise high enough in the backlog to be implemented is wasteful.

Remember that Product Backlog ordering is an art, not a science.  As leads of this process, POs must leverage input from their Development Teams and solution community stakeholders and their own intuition and experience.

When Not to Employ WSJF

If the product backlog is small or mainly populated with user story-sized items, computation of WSJF values may be overkill. However, it is still advisable to take the five ordering factors discussed here into account when ordering product backlogs.

Leveraging User Story Maps

Scrum Teams can leverage user story maps to organize an ordered Product Backlog across solution workflow steps, Sprints, and releases.  Scrum Teams may use them in tandem with Product Backlogs to help identify dependencies as part of backlog refinement.  We explain user story mapping and provide an example here.

Capacity Allocation

The Product Backlog contains all of the solution requirements (e.g., epics and user stories) for which the Development Team may implement features.  If it is not in the Product Backlog, the Development Team does not implement it.  However, just because something is in the Product Backlog does not mean it will be done.

In light of this, it is often difficult for teams to balance delivery of business or mission value with work necessary to:

• Implement back-end functionality or infrastructure that supports business/mission-facing functionality
• Perform system maintenance to ensure overall system performance and quality
• Address technical debt
• Explore new requirements and technical approaches to address them

One way Scrum Teams achieve the right balance between different types of work is through capacity allocation.  Teams allocate their capacity to do work within an iteration/Sprint.  They allocate percentages of that timebox to specific types of work.  For example, a team may agree to devote most of the next Sprint to developing new business or mission capabilities, but allocate a percentage of that time to address technical debt and maintenance.  The team agrees to the types of work they will perform, and the percentages of the Sprint those work types will consume, based on current needs and constraints.

Conclusion

The key to effective Product Backlog prioritization is achieving an optimal balance between competing factors.  “Optimal” does not mean perfect. 

The WSJF technique provides a simple way of accounting for those factors.  WSJF is only a tool to help make decisions.  It is not a deterministic process that renders an exact solution. 

Arriving at a “good enough” Product Backlog ordering depends much more on effective collaboration between POs, development teams, and solution community stakeholders than on applying the techniques discussed in this article.  Ultimately, the quality of Product Backlog ordering depends on Agile’s empirical inspect and adapt approach to defining and executing work.

---

[1] Don McGreal and Ralph Jocham (2018).  The professional Product Owner: Leveraging Scrum as a Competitive Advantage 1^st Edition. Scrum.org

Last Updated on January 4, 2023