Obsession with Story points

This seems like it would be a good discussion for a Sprint Retrospective. Although you may want to spend a little bit of time doing a lightweight inspection of the overall process and identifying process improvements, the majority of the retro time can be spent doing a deep dive into Story Points and what they are (generally in the industry as well as specifically to the team), how the team hopes to use them, and perhaps normalizing what 1 Story Point means. It may also be a good idea to look at alternative estimation methods.

What other conversations are taking place in the organization around story points?

It sounds like there's a perception that a higher number of points equates to greater value delivery. Does your organization value a greater delivery of story points? How is success measured?

If your organization has a success metric of some kind (e.g. an outcome such as product/feature adoption, average sale value, or lead conversion rate) maybe it's a good idea to make that transparent to the team, and help them understand how the work they do is impacting that metric.

I wrote a lot about estimation on this forum recently. It might be worth reading that and some of the other threads, just to see if it gives you a new perspective.

The purpose of estimation is for team members to get their arms around how much work they can take on in a Sprint. That's it. Everything else ought to be about empiricism: the actual release of "Done", valuable work. Each increment should be transparently finished and usable, the accumulating value being maximized by inspection and adaptation.

If value is perceived to lie in story points, ask why. They seem like a poor empirical measure of value to me.

Story Points are estimates.  An estimate is a best guess based on information known at the time of making the guess.  Making those guesses can aid teams in forecasting bodies of work based upon their past guesses.  That is the end of their usefulness.  They don't provide any value in determing a team's effectiveness, their ability to deliver or the value that is being delivered by the team. 

Once an estimated Product Backlog item is included into a Sprint Backlog, the estimate is no longer relevant.  Trying to relate an 8 point story from 3 sprints back to an 8 point story in today's sprint has very questionable value in my opinion.  I coach that you estimate effort before you start, then forget that estimate once you start working and focus on getting the work done. 

When I've been empowered, I've done away with sizing. I've asked a simple question. "Developers, how many PBIs can you fit within the next one-week sprint?" And then they would go move post-its (super sticky, always!) on the wall. Done.

Unfortunately, Agile is used by management and leadership to measure performance through a tool. In a case like that, it may not be your choice. And yes, the sprint planning will turn into an argument on whether each story is three points or five points. Throw in an Agile "coach" and that makes things even more interesting.