User stories that supersede previous stories: should they be obsoleted or acceptance criteria transplanted and marked done?



  • 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.



  • Why is time being spent on this debate? It's irrelevant.

    A key facet of Agile Software Development is satisfying the customer by frequently delivering valuable, working software. Is the team able to do that on a regular basis? Since this question is tagged /questions/tagged/scrum , to put it in Scrum terms: Does the team have a Product Goal? Each Sprint, are they able to craft a Sprint Goal that can help move the product closer to the Product Goal? Is the team able to consistently achieve their Sprint Goal? The answers to questions like this are the ones that matter.

    Based on the description, it seems like the team is measured more on completing stories or checking off acceptance criteria rather than delivering value and achieving goals. This can turn the team into a feature factory - mindlessly churning out changes rather than thinking about how to maximize value.

    As long as everyone - the team and the stakeholders - are in agreement about what work has been done, what work is being done, and what the next work will be, how you move stories and acceptance criteria around is just paperwork and not that valuable. If there isn't agreement and transparency about the state of the product, then that would be a problem to consider solving, but it would be better to approach it from that perspective rather than the mechanics of what to do with stories and acceptance criteria, neither of which are mandatory to be agile.




Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2