As a developer, when I change a story's epic / fix version (i.e. Aha! feature / release) I want that change reflected in Aha! so that my Product Manager will know that a story or bug was pushed out to the next release

  • Yen Pham
  • Apr 29 2015
  • Shipped
Release time frame
  • Dec 14, 2017

    Admin Response

    We have launched an enhanced Jira integration. This integration will allow you to make the release field a 2-way sync, along with several other new capabilities including the ability to:

    • Set record mappings for Aha! initiatives, releases, master features, features, and requirements and link them to nearly any corresponding record type
    • Map default or custom fields in Aha! to any “like” field and specify which direction the updates should flow (e.g. from Aha! or from Jira)
    • Automatically send outgoing changes from Aha! or choose to review and approve them
    • Import records directly from Jira to make getting started in Aha! easy
    Check out the blog post for more details.
  • Attach files
  • Yen Pham commented
    April 29, 2015 18:10

    One of my teams releases code weekly and another bi-weekly, so having this feature would help keep Aha! in sync more easily for area product owners & upper management for review

  • Guest commented
    June 17, 2015 22:35

    There is an issue of precedence / SOR when changes are made to the fixver in JIRA that get overwritten from Aha. This has cause numerous issues to the point where we have turned off sending releases to JIRA from Aha because we only track major releases in Aha, not weekly patch releases, but do from time to time release features in patch releases.

  • Bern Abplanalp commented
    September 28, 2015 13:46

    We're going to run into some data quality issues with releases without this enhancement. Aha already allows the bi-directional feed from JIRA to Aha to account for net new issues being created and added to a fix version (i.e. fix version already synched, user creates new JIRA ticket, adds fix version to JIRA issue, it shows up as new feature/item in Aha). This is essentially the remaining part of that use case, whereby an existing (as opposed to new) issue has to be deferred to another fix version. The use case in plain terms, supporting what the original submitter of this idea posted, goes like this:


    Use Case:

    1. In JIRA, open an existing ticket (call it #1234) that is a) already linked to Aha, and b) already has a FixVersion, which we will call "Coffee".

    2. In JIRA, change the Fix Version of that ticket from "Coffee" to "Water". The JIRA project does not change, just the Fix Version within that project that the ticket is associated.

    3. In Aha, ticket #1234 should no longer be in the "Coffee" release, but the "Water" release.

  • Rasika Dayananda commented
    November 06, 2015 04:03

     Not having this feature means significant duplication of work for us.  This is just adding to the agile noise

  • Rob Ormond commented
    February 24, 2016 04:33

    As part of our scrum process our dev team moves features between releases in JIRA, not having Aha! update automatically causes us big issues

  • Guest commented
    February 24, 2016 04:36

    We've just implemented Jira in our business and this is one pain point we have hit so far!

  • Rob Ormond commented
    February 24, 2016 04:52

    Re admin response, I am only concerned about changing the fix version, not epic.

  • alec ditonto commented
    May 24, 2016 01:44

    Admin - please give us an update on the status of this.


    Repro Steps:

    1. Go to a Jira project with at least two fix versions linked to two Aha releases

    2. Move a jira story that is linked to an Aha feature from one fix version to the other


    Expected Behavior

    1. The feature should change releases in Aha


    Actual Behavior

    1. It does not change releases :-(


    You guys are killing me!

  • Admin
    Chris Waters commented
    May 26, 2016 23:29

    We are thinking about this request. If the Fix Version is changed in JIRA to a Fix Version which is not linked to a release in Aha! do you have any suggestions for what Aha! should do? It seems like the best approach is to do nothing - the release in Aha! would not change in that case.

  • Rob Ormond commented
    May 26, 2016 23:39

    Chris, if you leave the feature in the release in Aha! then the two systems will have a different list of features/stories for the same release.  JIRA will have it in the other release that isn't in Aha! and Aha! will say it is in the release that JIRA does know about.  This will lead to some big issues I believe and not knowing which system to trust, especially when it is two different teams that use each system (for us our Product Team use Aha! and our Development Team use JIRA).

    In my opinion it should be removed from the release in Aha! too, but as far as I know a feature in Aha! has to have a release (not a requirement in JIRA) so I am not sure how you would manage that.

  • Ian McKelvey commented
    May 26, 2016 23:46

    Personally, I would like it if the feature were removed from Aha! in this case. It can be brought back in if we choose to bring the other fixversion/release into Aha!

  • Paul Edge commented
    May 26, 2016 23:48

    @Chris, how about a special Parking Lot for objects that need reattaching to a release? This would allow someone to watch that "release" and at least manually resolve the mismatch, e.g. by creating the corresponding release, linking the JIRA version to it, then moving the objects to the right release.

    Doing nothing makes it very hard to detect that there was a problem, and while the manual effort may be a pain, it is much better than realizing 3 sprints later that everything is out of sync with JIRA and you have no idea what happened when.

    There are bonus points for a UI design that leaves a breadcrumb in the original release so everyone can see where the issues was moved. Perhaps the breadcrumb expires after some time or other condition is met. In fact I think this differential view of how things have changed is more generally useful. See for instance the idea and comment thread for

    You have the foundation for showing diffs in the burndown charts. If you can just expose that kind of information in other kinds of view like the Feature Board in some way I think that would help a lot of different use cases, including the original story in this idea.

  • Ian McKelvey commented
    May 26, 2016 23:52

    I agree with what Rob said about not knowing which system to trust. Unfortunately right now I only "trust" Jira and then have to do comparisons frequently to make sure that Aha! is correct.

  • Rob Bedeaux commented
    May 27, 2016 13:04

    The bug referenced above has been fixed by Atlasssian and deployed in the following versions 6.7.14,  7.1.4 Server Please fix ASAP!

  • Akar Sumset commented
    June 07, 2016 07:55

    Thanks for the info Rob Bedeaux.


    Aha people, when will this be fixed?

  • Naill Mclean commented
    October 07, 2016 10:28

    I have hit this issue with my process where changing the release is not updating in Aha and would like for this to be resolved.

    Process for Enhancements

    Enhancements are created through Aha and Pushed to Jira

    We have weekly releases and two week sprints (Teams with Offset Sprint End Dates)

    I need the Engineer team so specify which release the feature has been completed in for communication reasons.

    Process for Bugs

    We have bugs that get added by the engineer team, to make them show in Aha they need to have a release against them for them to import from Jira to Aha (correct me if I am wrong). Currently I am using a Parking Lot style release where the bugs are then prioritized in Aha and worked on by Dev and put into an actual Release.

    When the Dev updates the release it is not feeding back into Aha

  • Karla Carpenter commented
    October 13, 2016 20:51

    At the higher level - yes i want whatever the release that is associated with a feature to be consistent in both Jira and in AHA. However, I am concerned about who owns the right to make that decision and the workflow in AHA to vet that and then make it final for synchronized updates. I hesitate to see Development make that decision given that changing scope can have larger implications than a sole developer may realize prior to moving a feature out of a release for whatever reason. I would like to see this implemented as a Dev recommendation to change scope with an appropriate entry as to reasons they are requesting the change for the feature that must reviewed and approved as a  Product Owner. Without that decision making structure in place, Dev teams would then be given improper authority to change the release plans without proper review by business stakeholders for non-technical considerations.

  • James Claridge commented
    February 23, 2017 04:46

    Any progress on this issue,

    It's making me consider dumping aha because I can't tell if its up to date or not up to date simply because the issues are not sitting in the versions we dictate whether through Jira or through Aha

  • Alvin Lee commented
    March 01, 2017 02:52

    Where are we with this?  I noticed that certain fields in the epic do reflect changes, such as issue details, comments, etc.   When I add a new story to an EPIC, for example, Aha does not reflect that.  

  • Joseph Flynn commented
    March 18, 2017 19:42

    Killing me!  I use Jira to map my features within Initiatives because I much prefer Story Mapping to design out my Initiative/Feature road maps.  I am constantly juggling features around different releases as part of the design. 

    1) As of now, none of my Story Map designs (placing features in releases) are getting uploaded from Jira to Aha.

    2) If Aha had Story Mapping as a way to design feature roadmaps this could be a moot point.

  • Joseph Flynn commented
    June 15, 2017 20:08

    This is fixed now in Jira.  Can someone check if it is fixed in Aha!?  My subscription lapsed.

  • hema P commented
    July 27, 2017 13:06

    This fix is critical to our success in using the Aha! tool in our entire product organization.

    Please fix this asap

    Thank you

  • Jason Slaughter commented
    October 30, 2017 19:35

    Like others here, I'm less concerned about the Epics issue and more concerned about the Fix version, which does not have a Jira API limitation.

    This issue was marked as a duplicate of this one, but given that these are two separate issues, could you consider breaking these apart into an Epic change issue and a Fix version change issue?

  • Tom Strader commented
    December 14, 2017 20:45

    Agree with Jason, the fixVersion is actually the more useful one.  It would be nice to change if it matched an Aha fix version.  If the fixVersion is not found in Aha, create it.

  • Ben Hampton commented
    December 14, 2017 21:03

    The Aha-Jira 2.0 Integration works great.  Thank you!