Ordering a product backlog is an economic argument, and it goes better when it is made in the vocabulary the rest of the business already uses.
Terms worth defining precisely
Cost of delay. The value lost for every unit of time a capability is not available. A compliance change with a fixed deadline has a cost of delay that is near zero until the date and enormous after it. A revenue feature in a growing market has a steady cost of delay every week. Dividing cost of delay by the duration of the work gives a ranking that beats most scoring schemes.
Sunk cost. Investment already made and not recoverable. It is irrelevant to the next decision, and treating it as relevant is the single most common error in backlog arguments.
Opportunity cost. The value of the best thing not done because this thing was done. Every ordering decision has one, and naming it out loud changes the conversation from whether an item is valuable to whether it is more valuable than what it displaces.
Total cost of ownership. Building is a fraction of the cost. Support, hosting, documentation, training and the drag every extra feature puts on future changes all continue for the life of the thing.
Customer lifetime value and cost of acquisition. What a customer is worth over the relationship and what it cost to get them. Together they set how much the product can afford to spend on retention against acquisition.
Value from several perspectives
The objectives ask for at least three stakeholder views, and the point of the exercise is that they genuinely differ.
Customers and users value the problem going away, with the least disruption to what they were already doing.
The business values revenue, margin, retention and reduced risk, on a horizon set by its planning cycle.
Operations and support value fewer incidents, fewer manual steps and fewer tickets they cannot resolve.
Developers value a system that stays changeable, because that is what determines the cost of everything after this sprint.
Regulators and auditors value evidence, traceability and controls that can be demonstrated rather than asserted.
A product owner who can state an item's value in each group's terms rarely has to win an argument by seniority.
Techniques for measuring value
Direct outcome measures. Conversion, task completion time, retention, support contacts per active user. Specific to the change and observed rather than reported.
Revenue and cost attribution. Deals influenced, churn avoided, hours removed from a manual process. Blunt, arguable, and still the language most funding decisions are made in.
Evidence-Based Management. Scrum.org publishes a set of Key Value Areas, Current Value, Unrealised Value, Ability to Innovate and Time-to-Market. It is not part of the Scrum Guide, and it is a useful checklist against measuring only what is already realised.
Scored comparison. Models such as RICE or weighted shortest job first turn several dimensions into one number. The score does not make the decision. It makes the reasoning legible so the decision can be argued with.