How to handle a change in acceptance criteria for a user story?

Question

I'm interested to find out how people deal with changes to acceptance criteria of user stories on a process level.

Example:

You write a user story with acceptance criteria for feature XYZ. That user story gets implemented in a sprint of release 1.0. Some time later for the 1.2 release the product owner wants the acceptance criteria to be different (e.g. 1 minute timeout instead of 30 seconds).

How do you handle this change? How does it change the status of your original user story? We're using JIRA/JIRA Agile and I'd be specifically interested in hearing if you e.g. re-open your closed user stories and work on them in a new Sprint.

We're using Confluence to write our product specifications and the user stories in the PS are loaded directly from JIRA via a query. If one was to change acceptance criteria of the original user story and reopen it - how would one ensure that the product specification for version 1.0 wouldn't change?

EDIT:

I need to add some more information about our process: every user story has as well as the acceptance criteria some steps which can be used to test these criteria. These steps are used to generate a verification/test protocol which is used to check that all product specifications have been implemented properly.

Now this means a change to the user story would directly affect even already reviewed and signed off product specifications and test protocols since data is loaded via the jira query. I guess that this might not be an adequate way to pull the content into Confluence, something more permanent seems advisable.

Even if we weren't using these direct/dynamic queries, the question is still valid: how does a change in requirements/acceptance criteria affect the user story?

Increasing the timeout is not a story at all. What is the value? — Sklivvz, Jul 22 '14 at 09:10
@Sklivvz I assume your comment was regarding John Saunders' answer below? — Timo Kosig, Jul 22 '14 at 12:41
I was referring to your "(e.g. 1 minute timeout instead of 30 seconds)" — Sklivvz, Jul 22 '14 at 15:47
Did your team decide on an approach to handle change in the acceptance criteria? — Ben Smith, Sep 23 '14 at 23:35
@BenSmith yes we did indeed. I added the solution as the accepted answer since it is different to anything that was suggested previously. — Timo Kosig, Sep 24 '14 at 15:18

John Saunders · Answer 1 · 2014-07-22T11:32:01.870

2

I would consider this to be a new user story, like "As a user, I would like the timeout increased to 1 minute for reasons best known to myself".

edited Jul 22 '14 at 11:32

answered Jul 22 '14 at 07:36

John Saunders

160,644
26
247
397

thanks for your reply. I'm not sure this would work as a story. All of our stories have acceptance criteria and steps which can be used to test those. If you have the original user story in the product specification for release 1.2 AND the new user story - testing the acceptance criteria of the original user story will always fail since the timeout was increased as part of the new user story. – Timo Kosig Jul 22 '14 at 12:43

Ben Smith · Answer 2 · 2014-07-28T12:47:06.647

1

So after the product has been released the Product Owner comes back to you and says that they would like:

1 minute timeout instead of 30 seconds

This could be deemed an issue; It's not a bug as the timeout facility works fine, it's just that they have an issue with the period. Hence you could create an issue, associate it with the original story, and then break it up into tasks to implement this change.

However:

how would one ensure that the product specification for version 1.0 wouldn't change?

If the original product specification stated a timeout of 30 seconds, but you have now changed it to one minute, then there is no getting away from the fact that the specification has been changed. Creating an issue and linking it to the original story will mean that you won't need to edit the original story though.

edited Jul 28 '14 at 12:47

answered Jul 25 '14 at 21:55

Ben Smith

19,589
6
65
93

1

your solution is close to what we implemented in the end. I've added an answer myself with the process that we use now. – Timo Kosig Sep 24 '14 at 15:23
@TimoKosig if my solution is close, why no upvote? ;) Glad you came to a decision about what rules/principles to use. It's one of those tasks which seems obvious at the end. – Ben Smith Oct 31 '14 at 17:27

Timo Kosig · Accepted Answer · 2014-09-24T15:46:26.140

Thank you everyone for your answers. We have since found a way suitable for us to handle changes to user stories.

What we ended up with are the following principles/steps:

Once a software version has been released all user stories which are part of the product specification for that release must not be changed anymore
If the acceptance criteria of the user story should be changed after the release, a change request is filed and linked against the story
The change request is then processed - in the course of it the affected user story is cloned, adapted to the changed acceptance criteria and then added to the product specification for the next release while the old user story is removed
The new user story can now be implemented during a sprint

This way we have a product specification for v1.0 which contains the unchanged user story and a product specification for v2.0 which contains the updated user story.

The important fact is that years later you could pick up the product specification for any version and test it against the acceptance criteria and still get a PASS. This wouldn't be the case if the original user story had been modified.

I hope I managed to explain this in sufficient clarity. Please let me know if I need to elaborate on any parts of the solution.

score 0 · Answer 4 · answered Jul 24 '14 at 07:35

0

I would say that your original story remains good. Given that there is value in the change of timeout, you have a clear need to change the acceptance criteria for your original story. This is especially true where your tests are automated. I would create a new story:

As a I Want to change the timeout value for fraggle thrunge bracket manipulation So That

Writing this new story will focus the mind wonderfully on the value that this change will bring about. If it adds no value, then don't do it.

answered Jul 24 '14 at 07:35

Derek Davidson PST CST

1,799
12
17

Thank you for your input. I'm afraid your solution wouldn't work in our scenario. The timeout value isn't something we want the user to be able to change/modify. It is a fixed value and after release 1.0 we found that it needs to be different to the value that was implemented. I've added an answer myself with the process that we now use to cover these changes. – Timo Kosig Sep 24 '14 at 15:21

score 0 · Answer 5 · edited Apr 30 '15 at 09:54

You can not change the acceptance criteria of the user story once it is done(yes, refer to definition of done).

If the product owner needs to change the user story acceptance criteria, he/she has to create new feature/user story with "Acceptance criteria".

If the change has come in the middle of the sprint and existing Acceptance Criteria will not make any sense to project, remove the user story from the sprint backlog and add this to new(change should not be accepted in the middle of the sprint) sprint with new/modified acceptance criteria.

How to handle a change in acceptance criteria for a user story?

5 Answers5