The beauty of Agile is its ability to adapt to change. One of the principles behind the Agile Manifesto is “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

Clients change their minds. Maybe they don’t like how something looks or functions once it’s using real-world, actual content. Maybe they thought of another, important scenario where the initial requirements just won’t work. Maybe there was a stakeholder shake up and the new members have differing opinions from the initial team.

There are innumerable reasons why requirements may change, and thankfully, Agile practices are nimble enough to handle the inevitable changes. Create a new user story with the new requirements, add appropriate acceptance criteria, refine it, and then arrange it in the backlog so that it can be incorporated into a future sprint. What is often understated (or even left unsaid), is thoroughly documenting these requirements changes.

While the new user story captures the updates themselves, it doesn’t necessarily address how the changes fit into the big picture or when/why/by whom the requirements changes were made.

The initial feature requirements are clearly spelled out. After implementation, a new user story was put in and completed to update functionality, but the updates weren’t integrated into the feature. Months later while users are testing against the feature criteria as part of the UAT process, they notice that the functionality does not match the feature requirements and put in a bug ticket. You’re now left to reconcile the bug ticket with the feature and user story requirements and to determine and explain the expected behavior. You know when the new user story was put in, but not who requested it and why.

There are multiple different ways of tracking requirement updates. Some of these methods include:

Adding notes into the new user story that state when the update was requested, who requested it, and any relevant information on why the update was requested.
Adding those same notes into the initial feature that state when the update was requested, who requested it, and any relevant information on why the update was requested.
Update the requirements within the feature description itself. Striking out irrelevant requirements while inserting the new can provide a full picture of the exact changes, but can also look cluttered and overwhelming when reviewing a feature with many updated requirements.
If possible, adding a tag to the feature each time the requirements are updated can also prove useful when running reports. If a feature had requirements updated 3 separate times, seeing the 3 different “updated” tags can reinforce where the teams efforts are going and why.
Creating an overall “change log” may also be useful. Similar to the user story and feature notes, this document can state the feature being updated, when update was requested, who requested it, and any relevant information on why the update was requested. While this document may not be visible or relevant for all stakeholders, it provides an easy-to-see, big-picture view of requirements changes on the project.

No matter the tracking method(s) used, use keywords and add enough detail so you’ll be able to find the update later. This is especially important if the reference “living” and can be updated multiple times.

For example – the client’s current designs use fire truck red #ce2029 for their H2s. After the initial round of feedback, the designer made an update in the existing design file to instead use tomato red #ff6347. Designs continued going through feedback and to accommodate a change that was made elsewhere, the H2 color was then updated to cherry red #D2024D.

My notes, in both the new user stories, existing feature, and change log, would look something like this:

Update 1/26/2023: Per feedback from Stakeholder A on 1/24/2023, H2 color has been changed from fire truck red #ce2029 to tomato red #ff6347. Designs have been updated per request, user story LMN has been added to accommodate this work.

Update 2/9/2023: Per feedback from Stakeholder B on 2/7/2023, H2 color has been changed from tomato red #ff6347 to cherry red #D2024D, as cherry red is consistent with new design elements used elsewhere. Designs have been updated per request, user story XYZ has been added to accommodate this work.

When a bug stating H2s are cherry red instead of tomato red or firetruck red is reported, I can search for a number of keywords, including “H2 color”, “cherry red”, “tomato red”, “fire truck red”, “#ce2029”, “#ff6347”, or “D2024D”, and will be able to see the trail of updates requested. My notes include the keywords that help me easily find the updates, but also include information around who requested the update, why, and when it was made, that I can then use to confirm that the reported bug is not an issue that needs to be addressed.

Requirements changes are inevitable, but documentation around the requirements changes should be too.