At work right now we're implementing a number of functionalities of a mobile app. Two of the screens of said app are very similar, but belong to different product flows and thus two separate user stories (A and B) were written. When the time came to work on these stories, one of the users stated that story X was developed that basically superseded both A and B, and I requested written confirmation of this, which I quickly obtained. Thus, I proceded to invalidate A and B for the current work sprint. However, when the time to review the work backlog came, I was told that I couldn't invalidate the previous stories because "the new user story builds upon the previous ones but doesn't replace them". I argued that I was told in writing that X specifically superseded A and B, but was essentially overruled.
From my personal experience (which might admittedly be biased), if a given user story is written to supersede another, the acceptance criteria of the old one should be transplanted to the new one and specified to have already been worked on, in order to maintain a single source of documentation for the current work item, instead of having to track down multiple sequential documents. I've been trying to research this particular use case in Scrum specifically, and in agile methodologies in general, to see what should be the appropriate course of action in a situation like this, but haven't found anything providing a satisfactory answer to this extremely specific situation, and would like the community's input on this issue.