Should you go back and change a user story if the development is different than expected? If the solution to the user story is not what is expected, the acceptance criteria will need to change. The user story itself typically doesn't change. Here's an example:
As a Producer, I need podcast audio files published on our schedule so that the Podcast Service can ad revenue-generating advertising valued at $150k per month to the audio files.
Not the best user story, but let's get some background. The Producer was expecting to publish the podcast files on a schedule of their choosing, but the Podcast Service maintains the publishing schedule independent of the Producer's desired schedule.
See the conflict? The Producer wants to control the schedule and publishing of podcasts, but scheduling and publishing are controlled entirely by the podcast service. It's impossible to send a date and time for publication to the podcast service because that service doesn't accept that data when transmitting the files.
The original acceptance criteria called for a date and time to be passed with the podcast audio files to the podcast service. The podcast service doesn't accept anything other than the audio files themselves. In this case, the acceptance criteria will have to change.
The Product Owner will need to go back to the Producer and explain the Podcast Service's limitation. The Producer may pull the card entirely because it no longer provides the expected business value.
Engaging an architect or expert on the Podcast Service system during the product roadmap or user story map planning might have avoided the development team's inability to complete the card as expected. The card needed more refinement before moving into a sprint. Agile is about having open conversations frequently throughout not only during the sprint but prior to the sprint.