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

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

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.

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?

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

Please fix this asap

Thank you

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

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.

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.  

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

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.

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

Thanks for the info Rob Bedeaux.

Aha people, when will this be fixed?

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!

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.

@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 https://big.ideas.aha.io/ideas/APP-I-1904.

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.

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!

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.

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.

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!

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

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