A challenging but critical aspect of the Product Owner’s role is to ensure the backlog is prioritized so that the most valuable and important items are being worked by the team. For major initiatives, the prioritization process can follow an economic model that ensures it provides a solid return and it can be gauged for fit with the organization’s vision and strategy. Cost and revenue projections can be forecasted for comparison purpose to select the best investment. Where the approach breaks down is for small features or tweaks to an existing product. In many cases, it’s very difficult and time-consuming to forecast the something like incremental revenue from a minor change.

This calls for a different approach for prioritizing backlog items for products that have already been released. The nature of the backlog items is also varied and dynamic. The Product Owner is faced with questions such as should we make some features changes based on user feedback? Maybe add some small new features? Which ones? Which bugs should we fix? Which technical debt should we address?

The Challenge in Action: An Ecommerce Example

Consider the backlog for an established ecommerce platform. The Product Owner might be juggling items like:

• Bug Fix: Checkout process sometimes fails on mobile Safari (reported by 15% of mobile users)
• New Feature: Add product comparison functionality (requested by customer support team)
• UX Improvement: Simplify the returns process (based on user feedback surveys)
• Technical Debt: Refactor legacy payment processing code (flagged by engineering team)
• Enhancement: Add wishlist sharing to social media (competitive analysis suggestion)

Enter WSJF

Weighted Shortest Job First (WSJF) is one approach that balances the value of each product backlog item with how long it will take to implement, prioritizing the most valuable items that can be delivered the soonest (i.e. providing business value the soonest).

The formula is: WSJF Score = Cost of Delay / Job Duration, where Cost of Delay = user value+business value+time criticality+risk reduction+other relevant measures.

The larger the score, the higher the priority. Also, certain weights can be applied to specific components of Cost of Delay to emphasize their importance in prioritization.

Remember our Product Owner who is overwhelmed by trying to gather that many data points for a diverse backlog? Gathering the information for all of the Cost of Delay components may prove to be too much and cause them to fall back to relying solely on their intuition to prioritze.

A Simplified Approach

What if, instead, the formula were simpler? Something like WSJF Score = Impact/Story Points, where Impact is a single number.

Initial story points sizing can be provided on unrefined backlog items relatively quickly. The Impact rating represents value or importance and can fairly easily be provided by relevant stakeholders. Both can be expressed using Fibonacci scale numbers.

Applying the simplified formula

For the ecommerce site, the backlog might include:

Backlog Item	Impact Score	Story Points	WSJF Score
Mobile checkout bug	8	3	2.67
Simplify returns process	5	2	2.50
Wishlist social sharing	2	3	0.67
Add product comparison	3	5	0.63
Refactor payment code	3	5	0.60

(the example above is an abbreviated list – in reality it could contain dozens of items, especially as the product matures)

The mobile checkout bug becomes the clear priority—it has high business impact and requires relatively minimal development effort.

Important Considerations

There’s an obvious caveat here: the Impact rating may be provided by different stakeholders with a possible apples-to-oranges effect across backlog item types (e.g. the dev team may perceive technical debt to be more critical than a new feature addition scored by the users and they might score it disproportionately higher).

To mitigate this challenge, consider establishing consistent Impact scoring criteria, e.g.:

• 8-13: Critical issues affecting core user workflows or revenue
• 5: Important improvements to user experience or business metrics
• 3: Nice-to-have features or minor enhancements
• 1-2: Low-priority items or experimental features

Reflections

Because the Impact is just one data point, it can be quickly applied to each backlog item without a huge amount of time invested (i.e. there’s a better chance that it will actually be done).

The Product Owner will still apply judgement and intuition in prioritization decisions, but at least they are now equipped with a data point to better inform their thinking.

The scoring exercise alone often reveals assumptions and sparks valuable discussions between stakeholders about what truly matters most to users and the business.