Preface

The 2011 Scrum Guide’s description of Product Backlogs replaces the word “prioritize” with “order.” The reason for this was that “priority” was too often equated with business value and categorizations such as High, Medium, Low, or MoSCoW9 (Must, Should, Could, Won’t). While business priority is important, it is not the only variable that affects the order in which you pull things off the Product Backlog.

📏 Product Backlog Ordering

To properly order your Product Backlog, you need to consider many aspects:

Business Value

The value created from implementing the feature: revenue, cost saving, customer retention, prospect customers, and future opportunity. Features that map closest to the product vision likely rank highest here. Example: A “make payment” feature that generates direct revenue.

Risk

The importance of a Product Backlog item in terms of exposure to a harmful situation. This includes both business and technical risk. The higher the risk, the higher it should be in the Product Backlog. Business risk example: A feature that must be implemented before a regulatory deadline Technical risk example: Implementing new technology on which a feature depends without knowing whether the technology solution will even work.

Cost/Size

The cost of implementing a feature. This is mostly (but not exclusively) associated with the effort and time that the Development Team needs to build it.

Dependency

Regardless of value, risk, and cost/size, sometimes a feature cannot be done before another. These can be both business and organizational dependencies.Business example: An authentication feature that must be completed before anyone can use the more valuable features Organizational example: A feature that depends on another downstream team creating a service for your team to use

🧪 A Formula

By finding a way to enumerate each of these variables, you can create an order ranking system in which the higher the number, the higher the item will be in the Product Backlog. Then make adjustments based on identified dependencies. By focusing on smaller valuable features, you risk that the large yet valuable items get ignored. As these are likely the more strategic initiatives, identifying them and breaking them into smaller (right-sized) deliverables becomes an important part of refining the Product Backlog. Items that are low value, low risk, yet cost very little should not necessarily be ignored either. Consider these as “fun-sized” and work on them if there is extra capacity or they can be taken by newer Development Team members who are still getting comfortable working with the product. Some organizations even open-source these items to other groups within the organization or even to the public. Obviously, the risky items that have little value should be ignored.

This formulaic approach to ordering could be a good start. Just do not consider it a magic formula to which you are bound. Ordering the Product Backlog is more of a nondeterministic problem. You shouldn’t strive for the best answer as it likely does not exist. Aim for a good answer and trust the empirical process of inspecting and adapting. A good Product Owner, with help from the Development Team, can use intuition and experience to order the Product Backlog just as effectively.

With this in mind, spending a lot of time ordering the bottom half of the Product Backlog can be considered somewhat wasteful. Focus instead on the order for the next few Sprints. Since you are refining as you go, the rest will work itself out.

Ordering the Product Backlog will open up many important conversations within your Scrum Team (and with stakeholders) that will clarify assumptions, misconceptions, and dependencies and thereby reduce accidental complexity. This process itself generates lots of value.

📐 Measuring Value, Risk, and Size

Value

If you can determine the monetary value amount of the Product Backlog item (e.g., this feature will make $300,000), then that would be ideal. However, it is rarely that easy.

Other approaches use somewhat arbitrary numbers to indicate value, much like with relative effort sizing. The number range does not matter as much as getting stakeholders engaged and using the wisdom of the crowd. There are plenty of facilitation techniques for this, such as:

• Business Value Game

  • Use planning poker to estimate value instead of size

• Buy-a-Feature

  • Innovation Game using money to purchase features

• 20/20 Vision

  • Innovation Game for simple ordering of a Product Backlog

• Thirty-Five

  • Collaboration activity for ordering

Using these democratic and inclusive processes with stakeholders for assigning business value to Product Backlog items has two main benefits for Product Owners:

1. They get a better overall sense of what their stakeholders are thinking.

2. Their stakeholders feel more included and heard.

Remember that business value is not the only factor when ordering a Product Backlog. Risk, cost, and technical dependency also play their parts.

Risk

The easiest way to measure risk is with a simple Low, Medium, High ranking provided by the Scrum Team. To use this system in the formula cited above, assign a number to each risk rating (e.g., L51, M55, H510). Ultimately, the scale you use to represent risk depends on other factors: How important is risk for your product? What scale are you using for value? Risk may not even need to be considered for certain products, while others may want to give risk more weight and more ranges.

Size

The most common scale to use when assigning relative size estimates to Product Backlog items is the Fibonacci sequence (1, 2, 3, 5, 8, 13, etc.). The next chapter on release management will get more into the reasons for relative estimation. For the purposes of ordering a Product Backlog, just know that the size of an item is a factor. However, what you name the unit that represents its size is not that important (often it is called a point or story point).

Refinement is a great opportunity to revisit this ordering each Sprint.

📚 Excerpt From Professional Product Owner, The: Leveraging Scrum as a Competitive Advantage

photo by airfocus