Allow moving a feature to a completed release

Just adding another please consider this to the many comments. This continually happens for us. Reopening a release just to include a feature that was forgotten feels like it muddies the process. The admin response here is absolutely the right way to deal with this if all things are working perfectly but being able to include a feature in a shipped release handles the time when things aren't working perfectly. This is a frequent issue for us and a huge frustration to have to constantly re-open releases to fix an error.

I see it as a data quality issue which others have pointed out here as well. Every once in a while I find an feature or epic that was actually completed in release that have been shipped, but that for one reason or another wasn't properly included in the release. Given that I cannot change the feature to a shipped release I have to resort to either:

• Re-open the release which is wrong since the release have actually been shipped.

• Set the feature to a later release which is also wrong since it was actually included in previous shipped release.

• Delete the feature which destroys information that may be good to have later.

If this were an admin-only capability, or something offered as part of an approval workflow, maybe that would be the right way to implement this. I can definitely say we wouldn't want everyone to think they can add features to shipped releases (i.e., late) as a standard practice. If folks have to "tell on themselves" to get it fixed we can still discourage the behavior, yet maintain data quality for ourselves in Aha.

I see that the status is set to "Unlikely to implement". I have just added a vote. Right now I have two choices that are both bad:

1. Reopen the release and ship it again

2. Delete the feature/epic

I'm resorting to reopening the release until this is implemented.

Revisiting this - Sometimes we import features from the development team that may track to tech debt. If we miss one, it makes it difficult to make sure we accounted for all features. While I understand the thought process, this has been something that I've searched the help for a few times.

We too experience this challenge and want to tidy up our stories against releases, please allow this as an option.

I had a feature marked “will not implement” that I wanted to stay with a shipped release, just so the context is clear. Can this be allowed? If we're not going to implement it, I don't want it moved to another randome release.

In theory, completely understand and respect the point above.  On a normal basis I don't need to do this.   But every once in a while I find something that did actively ship with a release, with no way of adding it to the release. 

This doesn't need to be supported everywhere.  Maybe from within the closed release I have an option to add a feature\etc from there as the override.

But otherwise to get this item into the right place, I have to re-open the release, add the item to it, and close it again, and make sure I go back and pick the right shipped date, etc.  Then I get an e-mail notification that I shipped a release.

I feel like this has even more potential for confusing people, and it changes the workflow dates because I have to navigate through the workflow.

I generate a lot of reports tracking capacity, time logged, areas of development focus (IE: How much of our time was spent on customer commits this release), etc, so it's important all of the features wind up in the right release if that's where the team managed to fit it in.

+1 - ran into this limitation this morning!