The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team. - Scrum Guide
The Product Backlog is basically a list of items (Product Backlog Items or PBIs) that represent the characteristics of the product to be built. This list of PBIs is a living and emerging list, constantly changing as you learn more about the product. It is maintained and ordered by the Product Owner and is the only source of work for the Scrum Team.
All the PBIs that make up the Product Backlog have a reason to exist, and that reason is to meet a particular Product Goal.
Product Vision
The product vision is the description of the purpose of the product. It should answer the question: what do you want to build it for? or what do you want to achieve?
To date, Scrum does not refer to a product vision, so we cannot say that it is an artifact of Scrum, although it is highly recommended to have it. For example, Spotify's vision is "We envision a cultural platform where professional creators can break free of their medium’s constraints and where everyone can enjoy an immersive artistic experience that enables us to empathize with each other and to feel part of a greater whole.” Google's vision is “to provide access to the world’s information in one click.”
We can agree that none of these visions can be measured, nor do they have a time horizon. In fact, they sound ambitious if not utopian. To measure your progress toward the eventual realization of the product vision, you must determine Product Goals’ achievement.
Product Goal
The Product Goal is defined within Scrum. It is a future milestone that you want to achieve through the product, but it measures results instead of scope. For example: “Increase the subscriptions of Asian customers to the Plus and Premium categories by 200%”.
The path towards achieving the product vision may have several different product goals over time. Your Scrum Team will need to hit one goal (or drop it) before pursuing the next.
Product Backlog Order
As I mentioned before, all the PBIs of the Product Backlog exist to achieve a specific Product Goal. Giving a clear order to the PBIs is essential because it will precisely determine the product evolution strategy and the priorities with which the developers will transform the PBIs into Product Increments.
I make a deliberate distinction between prioritizing and ordering. It has been my experience that when it comes to prioritizing, one option is to accommodate everything into three large groups: high, medium, and low priority. Unlike that system, the PBIs of a Product Backlog must be in a row, never sharing the same group, with certain exceptions that we will see later; that is why I refer to it as "ordered" in a row.
This “ordering” is the sole responsibility of the Product Owner and, although everyone within the team can make suggestions or recommendations, it is the Product Owner who has the last word about the final order of the items in the Product Backlog. This “ordering” also considers the business context, the product itself, and the market in which it is inserted.
Ordered by Product Goal Contribution
You can order the items in the Product Backlog based on the items’ contribution to the Product Goal’s achievement. We can understand contribution as the relevance that an item has for the fulfillment of the Product Objective.
An example that illustrates the contribution of the PBIs to the Product Objective would be: In a product whose objective is to increase the influx of students and facilitate the communication of the contents of the different careers of a university, it has been decided to create a website with different characteristics that are listed in the Product Backlog. Two of them are: 1) that the student can access the curriculum of the different careers and their contents, and 2) that they can make tuition and fees payments online using a credit card.
In this scenario, you might think that the PBI represented by online payment by credit card has a more significant contribution to the product objective than giving students access to the contents of the curriculums when in reality it is the other way around: 1 ) the fact that a student can access the contents of the curriculums of the different careers has a more significant contribution towards the fulfillment of the objective of the product (increase the influx of students and increase the communication of the curriculums) than what the online payment could contribute and 2) a student could continue to pay with a credit card over the phone or by bank transfer.
Ordered by Return on Investment (ROI)
Another approach you can use to determine the priority of a Product Backlog Item is to calculate the economic benefit obtained based on the effort that must be invested. Although it is a simple mathematical formula, this has the implicit problem of finding or knowing the economic value gained by incorporating a particular characteristic into a product. Once identified, the calculation is relatively simple:
ROI = benefit / cost
Cost represents the effort necessary for developing a particular characteristic of a product, and the benefit is the economic return obtained from its incorporation.
Ordered by importance and risk
Whether you order the items in the Product Backlog by contribution to the product objective or by ROI, we can call these “ordering by importance.” However, these sorting premises can be affected by the level of risk associated with each of them.
In this way, you should take advantage of Scrum's iterative and evolving construction framework to mitigate risks implicitly by first building those PBIs with the highest associated risk and leaving those with the lowest risk for later stages.
It is recommended that low-importance, high-risk PBIs be avoided.
Variable Scope
Since you can’t know in advance the product that you must build to achieve the objectives, it is to be expected that you will learn from customers, discover the business model and validate your assumptions. Scrum is a journey of discovery that you undertake together with your clients and, under this scenario, the Product Backlog must be a living element that constantly adapts to the rhythm of your learning and frequent feedback.
Traditionally, the scope has been fixed from the beginning, and thus cost and time has been managed as variable elements. In agility, this equation is reversed: time and cost are the project’s fixed components, while the scope is the variable component since it is what we do not know in advance.
The Pareto Principle
Wilfredo Pareto was born in Italy in 1848, where he grew up in an upper-middle-class family. He was a renowned engineer, sociologist, economist, politician, and philosopher. One of his most revealing studies, at that time, revealed that 80% of the land in Italy belonged to 20% of the population. From that discovery, various mathematicians and economists derived these observations and applied them in other contexts. One of them was Joseph Juran, who used the Pareto Principle (or the 80/20 rule) in 1941 and applied it to quality: 80% of the effects are produced by 20% of the causes. This law was also known as the Vital Few’s principles (the top 20% generating 80% of the quality) and the Trivial Many (the remaining 80% generating the remaining 20%).
If we apply this principle to product development, you will find that approximately 20% of a product’s characteristics solve 80% of the problem. And recursively, the remaining 20% of the 80% of the features solve the 80% of the remaining 20% of the issue.
Contingency Management
Considering that the scope is variable and that everything that is built is ordered in the Product Backlog according to its contribution to the product objective, we are going to use the least priority PBIs as the contingency against unforeseen events. This means that, by respecting time and cost, the scope with the lowest priority would be the one that would pay the price for delays or deviations. For this approach to be practical, the Product Owner's work and ability to facilitate the discovery of priorities by everyone involved are critical.