Business value of a userstory#20

We assign points and low/medium/high priority to user stories. I think we should also try to quantify the value to the end user/client of a user story being released into production. It might contain some nice code but how will it positively impact stakeholders such as end users who are not on our sprint teams?
An extra field in Jira etc would be simple to add to measure this. And demonstrate to the paying client how the scrum team’s work adds value to their paying users

I fail to see how this relates to Scrum or the Scrum Guide?

User Stories and Points are complementary (optional) practices. Therefore the addition of Business Value of a User Story doesn’t make sense, unless we add a host of other things, which were intentionally left out.

Agreed with Maarten. Also,I believe the SG should be as lightweight as possible, focusing on the empiricism part.

Agree with Maarten. Points and Stories are actually not part of Scrum, but only supporting elements a Scrum Team can choose to use.

Scrum JIRA template is not Scrum.

Value at the story level makes little sense given the overhead to maintain it. Rather value should be strategically aligned at the Initaitive level. Next we need to define value metrics that provide evidence of the value proposition found in the Initiative. It’s the intersection of value and metric based return that leadership cares about, they don’t care about individual stories because they have to look more broadly at the organization.

Business value is the value of the required change given by user and the result judged or re-evaluated by the user in the sprint review.
I agree that this not specific to scrum

We estimate PBIs (business solutions to problems with detailed enabling specifications), not User Stories. User Stories are there to discover and understand requirements they are a conversation between the team and the end user, they don’t map directly to requirements nor they represent solutions. They live in requirements/problem domain space, and estimating problems is a nonsense. We can estimate solutions. We estimate PBIs in Scrum.

Some teams assign value points, but that is not part of the definition of Scrum. I dont agree with using value points, it always seemed arbitrary and unnecessary to me.

The guide makes no mention of estimating. It does mention forecasts at least once. Might be worth while to realize that estimating should not be used.

The fact that value creation is never measured against cost always baffled me. How do you know that you create value if you dont have the cost?

I mean the first thing you always do is to make a hypothesis of features that you belive could generate value and then you need to prioritise what generate the most value. Without a cost that excercise becomes pointless?

Then when you evaluate, what are you evaluating if not the value generated, which by definition is ROI, both sort term and long term?