What to do with a user story that was completed but not accepted?

[Ruth Jiménez]

We have a user story in the sprint that was built meeting the requirements and by the time the end user reviewed, they said that's not what they wanted. The miscommunication happened between the appointed person to gather and communicate the requirement and the person writing the user story that was ultimately worked on, so the end user wants now a completely different thing. 

What should be the US end status if we completed it but it was not Accepted, thus not being deployed to Prod? 

[Mark Segall · Accepted solution]

This is not a tool based recommendation. In my Agile training it was taught that the story is always marked as Done whether it was ultimately scrapped, incorrect, or victim of scope creep with new stories being created for corrections.

If you want to keep everything inside the original story, it's not best practice, but you could add a reopened status with the following recommendations:

1. Conditional transition - You could have it where only the project lead or admins can transition to this status
2. Automation - Once in this Reopen status the issue goes back to the desired state (To Do, In Progress, etc). The automation is helpful because if you want to execute queries against any issue that's been reopened, you could do this:

Status was reopened

The end result is that you could technically capture the work complete as long as it is in your Done status at the end of the sprint.  Then find the issue and reopen it before you start the next sprint so it can be counted against velocity for the next sprint.  Again, I don't recommend this route, but this is a potential path if your process is not flexible.

[Mark Segall · Accepted solution]

Hi @Ruth Jiménez and welcome to the community!  I typically mark these as closed with an appropriate resolution and create a new linked issue for the updated requirement.  

[Sunny]

@Mark Segall Agree however, this has nothing to do with tool. It is a process decision. 

@Ruth Jiménez a tool should not dictate how you should work. It is your process that should guide how you use the tool. 

[Tina Behers]

@Ruth Jiménez Given that this question was asked in the Jira Align forum.  I'll assume that you want an answer on how to remove it from the sprint in Jira Align.  

From a process perspective, your framework, approach or methodology should include some basic definition of what to do in these situations.  While they may not happen every sprint, they are not rare occurrences. :) 

Regardless of issue type, feature, story, task, etc., sometimes we think we want or need something and later on determine we don't need it after all.  So we need a way to remove those items from our backlog.  In some organizations, simply deleting it is acceptable. In others, doing so is perceived/acknowledged as a compliance violation.  

In organizations that do not permit or desire deletion: these are generally classed as "Cancelled". 

Cancelled = requirement defined, but not needed. 

End status: Cancelled  

To remove an a story such as this from the sprint: 

A Team user with a role of Scrum master, product owner or Team coach, would need to drop the story from the sprint.  

- Note:  Users system level role permissions would need to have permission to drop the object type. In this case - Story - Drop would need to be enabled

Steps to drop a story: 

From the sprint view - select the story. 

On the story card - scroll down the right side links to "More Options" 

From the actions panel presented - scroll down to "drop Story" and click "drop"

To cancel a story: 

It must be removed from an active sprint 

Users system level role permissions would need to have permission to cancel the object type.

Steps to cancel a story: 

From the sprint view - select the story. 

On the story card - scroll down the right side links to "More Options" 

From the actions panel presented - scroll down to "Cancel Story" and click "Cancel Item"

I hope this helps both from a process and activity perspective.