Here's a simple idea. Try using the same sensibilities you use to calculate story points for user stories for estimating business value.
Story points reflect the teams assessment of the effort required to deliver a user story, relative to another presumably well-understood story that the team has some historical experience with. The magnitude of the effort is typically based on Fibonacci numbers, that is, 1, 1, 2, 3, 5, 8, 13, etc.. The process emphasizes accuracy over precision and pragmatic experience over analysis.
As teams gain experience working together, the number of story points delivered in each sprint begins to stabilize. But even though their velocity becomes more predictable, the value and impact of the work continues to vary depending on the stories they select to deliver. To ensure they are working on the most important stories, most agile teams depend on the good judgment of the product owner to prioritize the backlog.
When it comes to prioritizing work, measuring business value is the way to go, at least in theory. In practice, it's easy to get wrapped up in attempts to measure it. Do you monetize everything? Is it worth trying to develop a standard for comparing things like risk, improved product stability, regulatory compliance or customer satisfaction?
One approach to prioritization is to use value points to estimate relative business value for each user story. For a given story, will it deliver the same value as a reference story, twice, three, or five times (etc.) the value? You can compare these value points against the story points for each item to calculate a sort of pragmatic Return on Investment, without the overhead of a rigorous business value measurement program. Of course, you'll still need to consider architectural and technical dependencies to arrive at the scope for a sprint, but a fast assessment of business value is a great place to start.
Once a team's velocity has stabilized, the amount of work they deliver typically doesn't change in dramatic ways. So, at some point, mature teams may decide that velocity of work isn't worth measuring, because, by definition, it's mostly the same from sprint to sprint for stable teams. Measuring value points, on the other hand, makes sense because there are always options for delivering more value for the same effort. Great design practices, stronger collaboration, mature architecture management and better business insight -- all can dramatically improve the velocity of business value delivered. The goal is to do the right work, not more work.
Business value is the name of the game. It's what counts, and it turns out, it may not be that hard to measure after all.