Change requests in JIRA

A user story is a placeholder for a conversation about a possible requirement. Why have two stories, of 5 and 8 points respectively, for what appears to be the same conversation?

I am gathering metrics for numerous teams and sometimes it is hard to keep track on what is going on in each team. That is why it would be easier to have an issue type that helps easier identify change requests. The bosses want to know the number of changes that are happening. It would be impossible for me to go through each ticket and identify changes. So the idea is to simply filter out change requests and see to which story they are linked to. Now, the only question is how to estimate properly, should the teams estimate the change order simply with the aditional work it would take to complete the story? 

My first question is if a stakeholder has seen and reviewed the implementation of the first user story.

If a stakeholder has not yet seen the implementation of the first user story, I'm curious as to why they are requesting a change to it. You should be getting feedback at least once per Sprint from external stakeholders. The Sprint Review is an opportunity to get feedback on Done work and adjust the Product Backlog based on that feedback, among other objectives. Some teams may continually get feedback from some or all stakeholders as well.

If a stakeholder has seen the implementation of the first user story, why does their feedback need to be implemented immediately? Another way of looking at this is why can't the feedback go into the Product Backlog, go through refinement, be ordered, and delivered at an appropriate time?

If the first story is considered to be Done but is not acceptable to stakeholders, then it's worth spending some time to understand why the Scrum Team did not have a good understanding of what was necessary. I would consider it reasonable for a change to generate feedback (new Product Backlog Items or a reordering of the Product Backlog), but cases where the team gets refined work Done but it is unacceptable to an external stakeholder should be an exceptional event.

No, the stakeholder has not seen the implementation of the first user story because the change request happened before the sprint is over and the team is expected to deliver according to the new instructions. This is happening quite often and leading to frustration within the team. That is why the idea came to track the change requests better to show to leadership what the main reason is that the teams are not delivering as planned. 

And yes the organization is a mess :)

The bosses want to know the number of changes that are happening. It would be impossible for me to go through each ticket and identify changes.

Why? What exactly are they trying to learn from this metric? What changes (if any) are they trying to drive by knowing this number?

Are the Scrum Team committed to continuous improvement? If so, I would look to the team to help.

It sounds like there is a problem around changes of plan, and the perceived ability of the team to deliver. It sounds like management are trying to learn more.

What is the least wasteful way to learn more?

Could it be more helpful if the teams agree to just keep a simple record of every time this happens (e.g. "2020-06-29 09:00 John asked me to do X instead of Y")?

This might only need to be a short-lived initiative of a sprint or two, so the overhead might be a lot less than changing the team's current way of estimating.

Also, reporting on estimates is fraught with problems, like you're trying to make assertions based on guesses, and it can encourage teams to cautiously overestimate, thereby undermining the purpose of the estimates, plus you introduce an extra barrier to the team adjusting its way of estimation in the future.

No, the stakeholder has not seen the implementation of the first user story because the change request happened before the sprint is over and the team is expected to deliver according to the new instructions. This is happening quite often and leading to frustration within the team. That is why the idea came to track the change requests better to show to leadership what the main reason is that the teams are not delivering as planned.

I don't understand how a stakeholder is able to request a change to an implementation that they haven't seen yet.

It should be easy to track the number of times that a development team pulled in a Product Backlog Item into a Sprint, but then a stakeholder asked for changes to that Product Backlog Item. However, counting the number of instances doesn't address why this is happening, nor does it show the impact of these changes.

The things that I'd want to take a good look at are how the Product Owner is expressing Product Backlog Items, the visibility and transparency of the Product Backlog to stakeholders, and how the team is performing Product Backlog Items. It seems like there is a disconnect between what the stakeholders really need or want and what the representation of that is going into Sprint Planning.

I would not focus on the team "delivering as planned", however. Changes do happen. What I'd want to try to minimize the impact of changes and make sure that the team is working on something that is understood and valuable.

Work with your Product Owner and explain that Story Points are just place holder for discussions, it doesn't count it as metrics, I encountered this kind of issues on my previous Company, tracking Story Points as part of metrics and yeah it's really a mess, it gave me headaches all the time esp. when generating metrics.