0

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.

3
  • Not super clear what you're asking. Are you just looking for a commonly-accepted definition of 'supersede'?
    – Sarov
    Dec 17 '21 at 16:28
  • 1
    What's the end goal here? Is it to say the Sprint succeeded or failed, or to impact your burndown or velocity, or what? What's the practical (rather than political) issue you're trying to address here?
    – Todd A. Jacobs
    Dec 17 '21 at 19:07
  • Hi, welcome to PM.SE! You might want to research a bit about the difference between output x outcome. This might help you understand answers the community will bring to you.
    – Tiago Cardoso
    Dec 19 '21 at 19:56
3

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.