Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

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

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? 

3 answers

0 votes
Tina Behers Community Leader Feb 23, 2022

@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.  

0 votes
Mark Segall Community Leader Feb 22, 2022

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.

0 votes
Mark Segall Community Leader Feb 18, 2022

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.  

@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. 

Suggest an answer

Log in or Sign up to answer

Atlassian Community Events