How to reuse done user stories without rewriting/duplicating them

Question

Just to outline the current situation first.

We've recently had an QA tester added to the team on an existing project. The project has user stories in previous sprints which outline the objective, denote acceptance criteria and contain the tasks required to implement said user story.

Now that the tester has joined the team with the intention of automating the unit testing and acceptance testing for the aforementioned features he needs user stories and acceptance criteria added to the next sprint.

There are over 100 user stories which currently exist in previous sprints which now need automating.

Do I create new user stories to the same effect and copy and paste the acceptance criteria etc into the new user stories?

My other option is to move the old user stories into the new sprint and remove the done status on them. The problem with this in TFS is that the previous sprint will then have no user stories in it and therefore no record of what was completed during that time.

How do others approach this problem?

Answer 1

TL;DR

Do I create new user stories to the same effect and copy and paste the acceptance criteria etc into the new user stories?

No. Don't do this.

This is new work, and therefore must be placed on the Product Backlog, prioritized, accepted into a sprint during Spring Planning, re-estimated, and appropriate implementation tasks added to the Sprint Backlog.

Stories are Not Specifications

If you're using user stories as acceptance test specifications, you're Doing Scrum Wrong™. A story describes a need or a feature, and leaves it up to the self-organizing team as it's currently constituted to find the best way to implement it. Putting detailed specifications into a user story defeats this purpose, and using legacy estimates and task breakdowns doesn't leverage the current team's knowledge, experience, or lessons learned to optimize the story

The Stories are Not Identical

You have posted no examples, but I can't imagine that a properly-written user story can be duplicated exactly and remain meaningful. For example:

As a user,
I want feature foo
so that I can effectively quux.

is not the same as:

As a QA tester,
I want the regression tests for the foo feature to be automated
so we can leverage a continuous integration system to prevent regressions.

Even if the features to be tested are the same, the viewpoint and the underlying goals are not identical, and the stories will therefore likely have different tasks needed to implement the stories.

Backlog Items Must Be Re-Prioritized and Re-Estimated

Is this new automation feature more important to the Product Owner than some other greenfield feature? The only way to be sure is to add the automation stories to the Product Backlog, and allow the Product Owner to prioritize them.

As the team accepts these stories into sprints based on backlog priority and current team capacity, the stories will also need to be re-estimated based on:

1. Current team capacity.

   Automation stories may not change your overall velocity, but they will likely reduce your capacity available for new features.

2. Current team knowledge.

   What was a large story 20 sprints ago may now be a small story based on new team knowledge or processes. Then again, maybe the team now knows more about how complicated certain types of testing are, and the old 3-point testing story is now really a 20-point integration story with many more dependencies. This detail should be driven out during Sprint Planning.

3. Current tasks needed to implement the story.

   Developing product features rarely consists of the exact same tasks needed to automate infrastructure or testing. There are edge cases where automation was addressed early in the project as part of the "definition of done," but new work always requires new estimates.