Skip to Main Content
Status Unlikely to implement
Created by Chris Waters
Created on Jan 8, 2015

Allow moving a feature to a completed release

Project Management is hard. I occasionally find tasks that were scheduled on a later release, but ended up getting completed, possibly due to a duplicate task, or the dev team pulled in a task from a future release.

This is a pain since I have no way to just say "This task is completed, and was shipped on release x.y.z". Jira allows this, and it's very handy when you need it. In Aha!, I have to jump through crazy hoops to do the same think.

Please add the ability to move a task to an already released "release" so it will be easier to clean up such items when you find them.
  • ADMIN RESPONSE
    Feb 5, 2016

    As noted, features cannot be moved to shipped releases. As teams work on specific features, we would recommend moving them into the existing release for better tracking throughout the release process. This would allow you to see progress by the team over the course of the release.

    At this we do not have plans to make updates in this area based on community feedback and current priorities. We hope you can understand.

  • Attach files
  • Guest
    Reply
    |
    Feb 18, 2024

    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.

  • Guest
    Reply
    |
    Feb 6, 2024

    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.

  • Jean-Marc van der Kolk
    Reply
    |
    Feb 6, 2024

    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.

  • Megan Sullivan
    Reply
    |
    Sep 25, 2023

    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.

  • David Bowen
    Reply
    |
    Jun 9, 2023

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

  • Brent Schumann
    Reply
    |
    Jul 26, 2021

    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.


  • Guest
    Reply
    |
    Jan 2, 2020

    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.

     
  • Spencer
    Reply
    |
    Nov 16, 2017

    +1 - ran into this limitation this morning!