Should a change request impact original user story?

Question

I am working with an organisation that has a continuously evolving product. Although original product is in production, business is regularly giving new requirements or change requests. The teams are following agile methodology. While new requirements are clear, it is not clear how the change requests to a delivered User Story should be handled. Some times the change request impacts multiple business stories. Should such change requests be tracked as a specialised work item type and linked to impacted user stories and should the original user stories be updated to reflect the new functionality (single source of truth for product definition) or should the change request itself is enough to handle and let the User Stories be kept as is as they are already marked as done.

Please note we are managing work items in products like TFS or Jira (depending on the project) but the process is similar.

---

[Update after response by Todd as the comment field was too short to fit]

My concern is also about the single source of truth. As we get past initial releases, the design of the software tends to degrade due to local fixes in absence of a complete view. Many times the change request user stories only focus on local aspects and developers loose the big picture. This can be avoided by the CR updating the original US and then the US being part of the work rather than the CR. CR would simply be linked to impacting US. CR can still be considered for work item tracking. But the acceptance tests would still be from the US. Does this sound practical? This should also help new team members joining. People change is common and in larger projects, there is also a practice of rotating team members. In absence of updated US, new developers need to depend on BA maintaining the documents outside the ALM systems like TFS/Jira.

Answer 1

I'd suggest to track and keep a complete end user documentation somewhere else (e.g. wiki, confluence - not a single document), perfectly versioned together with the system. A new user story needs a change in the code, test cases and docs. You can link it back but better link it to the docs.

Initial docs are copy-pasted from the initial stories and then updated. Issue tracker gives you a history of what, when and why it changed but it's not realistic to be a source of truth of current status.

Perfectly make your Behaviour-Driven-Development tests a runnable documentation.

Answer 2

TL;DR

Work is work. Truly agile frameworks embrace change, and don't track change requests. Instead, all work of any kind required to iteratively or incrementally evolve your product should be made visible as new work that consumes project resources.

Analysis

A "delivered" user story is not a thing you should be tracking outside of the iteration in which it was delivered. The second principle defined by the Agile Manifesto says:

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Even if you decide to track product or story deltas for some reason, an agile methodology operates at the product level. The focus should always be on evolving the product, not on change-tracking individual user stories. The latter is an anti-pattern based on waterfall thinking, where the goal is often to "hold someone accountable" for change, or for failing to forecast a future need. Don't do that!

So, what does that mean in practical terms? It means that you shouldn't be filing change requests against existing user stories. Instead, you should be writing new user stories that reflect work that needs to be done to evolve the product.

User stories or Product Backlog Items (PBIs) should only be tracked on the Product Backlog as future work, or within an iteration as current work. Once delivered, they are reflected in the team's velocity or other metrics to help improve future estimation practices, but are otherwise ephemeral artifacts that should be discarded once their usefulness is over.

Ticketing Systems

Even if you're using a ticketing system like JIRA, tracing a user story or task to a parent object should only be done for visualization of current or future work. Keeping information local in the current ticket reduces cognitive load when compared to chasing down information in linked tickets. For example, it's okay to say something like:

As a user, I want the widget ensmallened so it will fit in my pocket. NB: In ticket foo we embiggened the widget. Perhaps we can just back out that change.

Even better yet would be to copy the information about the previous change to the local ticket, saving your team or stakeholders a lookup every time they want to see what needs to be done now to meet the current objective. Spelunking into historical tickets is muda from a systems-thinking viewpoint, and definitely an anti-pattern for most agile methodologies.

Delivered tickets are a sunk cost. They are simply not relevant to work that needs to be done now to converge the existing product to a desired state. By treating new tickets as change requests on old tickets, your process is mistakenly valuing the amount of work previously done more highly than the amount of effort required to deliver on a current requirement. This is one of the many reasons that frameworks like Scrum require backlog items that aren't completed within the time box of a single Sprint be re-estimated and re-prioritized before being pulled into another iteration.

In short, if the business is requiring you to do this, stakeholder agility training may be in order. If it's just something you thought was a good idea, please don't do it anymore. Either way it's an anti-pattern, and the process needs to evolve to be more agile and more open to embracing change.