Tool to Prioritize Product Backlog Based on Relative ROI

Over the weekend, I created a tool called Relative ROI Calculator to help Product Owners (PO) of Scrum teams to quickly prioritize user stories based on their ROI (compared against one another).

This tool is meant to provide a framework for team discussion to answer the question: What are the most important things that we should we work on next?

The problems with current backlog prioritization methods

Most Scrum teams are good at estimating the amount of effort to complete each story, but not very good at estimating the value that the completed story will produce. This causes the product backlog prioritization to be misaligned from its mission and purpose of the product.

Few typical prioritization methods:

  1. Based on ease/cost of development (low story points first)
  2. Based on Product Owner’s preference first (i.e. flashy feature that’s trendy now)
  3. Based on his stakeholders’ demand (i.e. the ones that would make the stakeholder’s number look good). Essentially the PO is using product development as a way to gain favor from stakeholders.
  4. Based on team consensus. The team argues for what should be prioritized higher. In this case, the loudest and most articulate voice wins.

The first problem that could arise is the team gets demotivated. If the prioritization is dictated by the PO based on what he considers important without an understood set of criteria, the team can lose trust and get demotivated. The same goes to using the team consensus method. The team members who can’t articulate their arguments very well or not vocal may be discontent. To motivate a Scrum team, you need to create an alignment of purpose.

To motivate a Scrum team, you need to create an alignment of purpose.

If everyone in your team understood why the backlog is prioritized a certain way, which should be aligned with the bigger purpose of the product, then they would be motivated to fight to get the stories done.

The second problem is that the end-users (customers) are not considered. None of the methods mentioned above take the end-users into account. Without this, how can we honestly say that our backlog is prioritized based on what deliver value for our customers (1st Agile principle) ? And if we don’t deliver value for our customers, how can we capture value from them as a business?

Using Relative ROI to Prioritize Your Backlog

To calculate ROI on the story level, we need both the cost and the value that the story will give us. For the value side of the equation, we need both the value for the business and the customers.

This concept is based on Goal Centered Design Process by Alan Cooper and the Design Thinking approach of IDEO.

The Relative ROI Calculator, has all 3 pieces :

  1. Business : Conversion funnel metrics based on Dave McClure’s Pirate’s Metrics
  2. Customer : How many users are affected and how often based on Dr. David Travis’ Red Route Analysis
  3. Cost : Story points

All you have to do is answer the questions (filling out a short form) then the calculator will give you a Relative ROI score. After you do this for few stories, you’ll see how they compare against one another in terms of the ROI.

The Relative ROI score doesn’t mean anything in isolation.

The Relative ROI score doesn’t mean anything in isolation. It’s meant to be used as a tool to compare one story against another. Similar concept as the story points.

When to use this tool?

This tool is meant to be used as part of tactical planning, when you already validated the customer segment (persona) and their problem/motivation (needs/wants). You also have validated that your product does solve your customer’s problem either through prototypes/vaporware or if you have an existing product.

You have a product backlog populated with user stories as a result of doing the strategic work of gathering insights/requirements from customers and business stakeholders. Now you need to prioritize them so your team can start working on them.

How to incorporate this tool into your workflow?

1. PO working solo. It can be used by the PO independently to prepare the business case for the user stories that he will then present to the team during planning to back up his prioritization.

2. Workshop with team. The recommended use is to use this tool as part of a workshop with the team to create an alignment on what they collectively consider important. The fields in the tool’s form would give


Please drop me a note and give me feedback on how to improve this tool if you use it.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.