1

I am working with a team that is maintaining case management software. We are suffering from drift between different specifications, agile artefacts, implementations and understandings. I would like to propose a solution to the team that aligns with agile methodologies that works for our team.

Frequently, we will get a request to "show additional data X about entity Y on screen Z", where X may be an existing or new field/property, and Y and Z are almost always an existing entities / screens.

There would have already been a user story that has long been closed: As a user ... I want to see information ABC about entity Y so that I can ..., which would have been used to create the screen in the first place.

Typically field X would just be another piece of information that is not important in itself, but is important when in the context of entity Y. I would find it hard to justify having a story purely to see field X, and other stories typically look at collections of data, not single datums.

Should I:

  1. Create a new story As ... I want to see X about Y so that I can ... - this keeps closed stories closed, and means smaller, more incremental stories, but also means that the old story is no longer current, so I can't treat it as part of the documentation.

  2. Re-open the old story and update the acceptance criteria As ... I want to see ABCX about Y so that I can ..., and then create a task Add field Y to Z - this means that stories, tasks (and other artefacts) are all up to date. Typically, the

  3. Some other solution? Perhaps use a feature/epic/whatever to track screen Z, and keep that up to date with all the fields about entities that screen Z would display, and then use method 1 and reference the feature?

  4. Something completely different?

Improve this question
2

1 Answer 1

Reset to default
7

You should not reopen an old story. You should create a new one and if it is in any way connected to the old one, you could put a link to the old one in the new one.

New requirements are completely new work and add new value to the Product, so definitely go with the new Story.

Improve this answer
2
  • Couldn't add anymore to this. It's one of the few places in agile development that is pretty much cut and dried. Done is done. If you buy a pickup truck from the dealer and then a year later want to get the tow package, that's a new purchase. Same logic with User Stories.
    – Joel Bancroft-Connors
    Commented Jan 18, 2017 at 17:16
  • Beside of full support of this answer I recommend to also highlight the parts of original story acceptance criteria which became obsolete. It would save time in the future for sure. (Don't update, just highlight or put couple of words.)
    – Vlad
    Commented Jan 18, 2017 at 18:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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