Does it make sense to reopen closed User Stories in a Scrum project

Question

I was asked to adjust our ticket-workflow and I don't know if it's a good route that we're taking here. So I'd like to ask for your opinions.

Our project is being developed based on a Scrum process with weekly sprints. As project management we use JIRA + Agile. We're around 10 people working on that project. However, around 50% are working from remote.

Our current workflow of issues is:

1. [Product Owner] Open
2. [Developer] In Development
3. [Developer] In Code Review
4. [Tester] In Testing
5. [Product Owner] In Acceptance
6. [Product Owner] Done

Currently, if a ticket / user story is marked as done, the code changes get merged into the master branch. We also at the moment can't reopen a closed (Done) ticket. If there is a defect which - maybe directly - can be connected to a previously closed ticket, we create a new one. However, we had a discussion on adding the possibility to reopen a ticket.

From your point of view, does this fit within a Scrum-process? Does it make sense to reopen a closed / into master-branch integrated ticket? Should this only be applicable for tickets from the current Sprint or release? What are the advantages and disadvantages of such an approach?

Answer 1

TL;DR

Newly-discovered bugs and defects are new work. As such, they must be made visible and move through the standard Scrum processes.

Analysis and Recommendations

If there is a defect which [maybe] connected to a previously closed ticket, we create a new one. However, we had a discussion on adding the possibility to reopen a ticket.

If you knew about the defect before closing the old ticket, it should never have been closed since it likely didn't meet the Definition of Done. However, a newly-discovered defect isn't a continuation of old work; it's actually new work.

All work must be made visible as a cost to the project. This certainly includes defects. The fact that the defect was discovered after feature development was ostensibly completed should be made visible, too.

Therefore, the rule of thumb is that you should start a new user story (e.g. open a new ticket) that captures the work and the project value for fixing the defect, and then allow the Product Owner to prioritize this new work on the Product Backlog as needed.

The ticket can certainly refer back to the previous ticket if doing so adds useful information or adds value in some way, but it's still new work and needs to make its own way through the Scrum process, including Backlog Refinement, Estimation, and eventual transfer to a Sprint Backlog whenever it's accepted during Sprint Planning.

Recycling completed stories is generally an attempt to shortcut the planning and estimation processes in Scrum. Even if this isn't what you're trying to do here, just remember that there are never any shortcuts allowed in the Product Backlog->Sprint Backlog lifecycle; that lifecycle and its related processes are fundamental to the successful implementation of Scrum.

Answer 2

it usually depends on your team process. In our team, once we close the story the QA starts opening up defects. However, the story only gets the QA approval when there is no outstanding sev 1 or sev 2 issues at the end of the last iteration.

Answer 3

The question about the sense of reopening stories may be the wrong question.

If you want to reopen a story, this may have the following reasons:

1.) You accidentally closed it. It is completely okay, to reopen it in this case.

2.) The closing of the story was okay, but the result is not satisfying. Do with the story what ever you want - quickly - and concentrate on the important work:

• The Team misunderstood the acceptance criteria => Improve the understandability of future stories.
• The acceptance criteria were incomplete => Improve the completeness of future stores.
• There is missing sth. in you DoD => Improve the completeness of you DoD for the future.

In my opinion, it's important to make things transparent. Try to avoid reopening userstories. In most cases, this is a sign for the need to change something.

Answer 4

I understand once you said the user story is done it means there was acceptance from the Product Owner if not from the user and then only the code was merged to your master. If that is a case then from in my view your user story is accepted & closed, any changes should be recorded as new story to the product backlog.