Maintenance/Change Management of User Stories in Agile Work Bench
I was going through the Agile work bench in 7.4 to capture the requirements as user stories and features. I understand that we can design the feature in a way that it mimics our case life cycle and have the user stories mapped to the case.
The question I have is related to the maintenance/change management of the user story. For example, I have a feature F1 and a User Story US1. In sprint 1 we have implemented the US1 and later it was found out that we need to make significant changes in the implemented user story. Now we cant go back to the implemented user story since it is already marked as Implemented. In this case I have to create a new User story US2 under F1 to change few functionalities done in US1
Down the line when application is huge and when these user stories are imported the user is presented with US1 and US 2 but its hard for the user to understand which one is implemented and which among the user stories functionalities are implemented. Here is where I dont understand how we manage the user stories. This is not an issue with use case model because the BSA always overrides the use case with the changes and end user is provided with the upto date information instead of having multiple duplicate use cases.
To All Pega BSAs, How can we have proper change management using user stories and features?
I am not 100% sure if I got the use case right but this is my understanding.
In US1 you implemented a screen where there is a field called XYZ
In US2 the field was changed to ABC
When you finally export stories to excel you will see a list with these 2 stories. And it would not be possible to tell which user story was implemented first and what is the latest ABC or XYZ
I believe the information about the features of the product that is the field information ABC vs XYZ shall be maintained in the feature description (which can contain link to external documents) and the feature documentation shall be updated per release.
Also this behavior will be same with other project management applications also.
The differentiation Agile workbench provides are
1. Stories are per application and version , which means that if you implemented US1 in Release1 and US2 in Release2 , Those will be visible in the Agile workbench of the Application version of that particular release.
2. By the update date time, you can always know which one was closed first and which one was closed later.