Using Relative Weighting to Determine Product Backlog Priority

Originally Published May 2020. Updated March 2024.

Imagine you’re a Product Owner, juggling a large Product Backlog of features, with stakeholders screaming for them to be done. How do you decide which one to implement first?

Enter Relative Weighting, a prioritization method introduced by Karl Weigers in 1999. This method is your secret weapon to prioritize requirements based on user input, feedback, and the expert judgment of your team.

Download the free Excel workbook at the end of the article.

A Step-by-Step Guide, Example Below

1. Assign Weights to Benefits and Penalties: Think of a feature. What’s the advantage for users if this feature makes it to the final product? That’s your benefit. Now, what’s the consequence for users if this feature doesn’t make the cut? That’s your penalty. Assign weights to these benefits and penalties based on how your company values them. For instance, if you believe the benefits outweigh the penalties, assign a higher weight to the benefit.

2. Determine the Weight of Cost and Risk Percentages: Next, determine the weight of cost percentage and risk percentage. If your project is high-risk, you might want to assign a higher weight to the risk.

3. Rate Each Feature’s Relative Benefit and Penalty: With the weights set, it’s time to rate each feature’s relative benefit and penalty. Use a consistent scale for this rating.

4. Calculate the Total Value of Each Feature: To derive the total value of a feature, use the formula:
   (Benefit * Weight) + (Penalty * Weight) = Total Value

5. Estimate the Relative Cost and Risk: After estimating the total relative value and value percentage for the features, ask your team to estimate the relative cost to implement each feature. Then, estimate the relative risk.

6. Calculate the Percentages: After noting the values for relative benefit, penalty, cost, and risk, sum up each column. These totals will be used to calculate the percentages.

7. Determine the Priority: The priority value can be calculated using the formula:

   Value Percentage / (Cost Percentage * Cost Weight) + (Value Percentage * Value Weight)

8. Sort the Priority Column: After obtaining the priority values, sort the priority column in descending order so that the highest priority items are at the top. As items are added to the product backlog or more information about a story emerges, reassess priority.

By adopting this approach, you can better understand the ranges that work for your team and stakeholders. It also helps ground discussions as it can be challenging to objectively factor in elements such as benefit, penalty, cost, and risk for each feature.

Weigers suggests calibrating this model with a set of completed requirements or features from a previous product. Adjust the weighting factors until the calculated priority sequence agrees with your after-the-fact evaluation of how important the requirements in your test set really were. This model can also help you make trade-off decisions when evaluating proposed new requirements. Estimate their priority using the model to tell you how they match up against existing requirements, so you can choose an appropriate implementation sequence.

For more insights on relative weighting, check out Karl Weigers’ books on Amazon: Software Requirements, Second Edition and More About Software Requirements: Thorny Issues and Practical Advice.

Relative Weighting: Example

Weights. The weights are arbitrary numbers that represent how your company values benefits and risks of features. It is very similar to how a teacher determines what weight to give homework, attendance, quizzes, and tests in determining the overall grade; it will vary from teacher to teacher. If you decide that the benefits outweigh the penalties, make the weight higher than the penalty by whatever ratio you see fit. If you decide that penalties outweigh benefits, adjust the weighting accordingly.

Once we have our weights set, we ask the users to rate each feature’s relative benefit and relative penalty. The relative benefit is the value that the feature will deliver; relative penalty is the potential negative impact of not doing the feature.

For example, let’s say one possible feature is “Make the widget comply with the Sarbanes-Oxley Act regulations.” There is virtually no relative benefit to users, but the relative penalty to the business is great - not doing it could put the company out of business. As such, we might see a score of 1 or 2 for the relative benefit and a score of 8 or 9 for the relative penalty.

In the following example, users rated the relative benefit of the feature “Query status of a vendor order” as a 5. They rated its relative penalty as a 3. To derive the total value of that feature, we multiply the two numbers by their relative weights and add them together:

(Benefit * Weight) + (Penalty * Weight) = Total Value

(5 _2) + (3_1) = 13

In this case, the total value for the feature is 13 points.

When we get the total relative value and value percentage for the features, we move away from the users to get insight from the team. We ask the team to estimate the relative cost to implement each feature using the same scale. Karl Weigers explains, “Developers estimate the cost ratings based on factors such as the requirement complexity, the extent of user interface work required, the potential ability to reuse existing designs or code, and the levels of testing and documentation needed.”

After we estimate relative cost, we estimate relative risk. Again, Weigers says, “Developers estimate the relative degree of technical or other risk associated with each feature on a scale from 1 to 9. An estimate of 1 means you can program it in your sleep, while 9 indicates serious concerns about feasibility, the availability of staff with the needed expertise, or the use of unproven or unfamiliar tools and technologies. The spreadsheet will calculate the percentage of the total risk that comes from each feature.”

After we note the values for relative benefit, penalty, cost, and risk, we sum up each column. These totals will be used to calculate the percentages.

• Total value percentage: Divide the sum value of the relative benefit and penalty by the total sum at the bottom.
  • In the example, this is 13 / 154 = 8%.
• Relative cost percentage: Divide the relative cost value by the total relative cost sum at the bottom.
  • In the example, this is 2 / 42 = 4.8%.
• Relative risk percentage: Divide the relative risk value by the total relative risk sum at the bottom.
  • In the example, this is 1 / 33 = 3%.
• Priority: Divide the value percentage by (cost percentage * cost weight) + (value percentage * value weight).
  • In the example, this would be 8.4% / ((4.8% * 1) + (3% * 0.5). This gives the priority value (1.79).

After we obtain the priority values, we sort the priority column in descending order so that the highest priority items are at the top. As items are added to the product backlog or more information about a story emerges, we’ll need to reassess priority.

In the end, the data looks like this: