Skip to Main Content
142 VOTE
Status Shipped
Categories Jira
Created by Guest
Created on Apr 29, 2015

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

No description provided
  • ADMIN RESPONSE
    Dec 14, 2017

    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
  • Ben Hampton
    Reply
    |
    Dec 14, 2017

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

  • Tom Strader
    Reply
    |
    Dec 14, 2017

    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.

  • Jason Slaughter
    Reply
    |
    Oct 30, 2017

    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?

  • Guest
    Reply
    |
    Jul 27, 2017

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

    Please fix this asap

    Thank you

  • Joseph Flynn
    Reply
    |
    Jun 15, 2017

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

  • Joseph Flynn
    Reply
    |
    Mar 18, 2017

    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.

  • Guest
    Reply
    |
    Mar 1, 2017

    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.  

  • Guest
    Reply
    |
    Feb 23, 2017

    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

  • Karla Carpenter
    Reply
    |
    Oct 13, 2016

    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.

  • Guest
    Reply
    |
    Oct 7, 2016

    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

  • Guest
    Reply
    |
    Jun 7, 2016

    Thanks for the info Rob Bedeaux.

     

    Aha people, when will this be fixed?

  • Rob Bedeaux
    Reply
    |
    May 27, 2016

    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!

  • Guest
    Reply
    |
    May 26, 2016

    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.

  • Guest
    Reply
    |
    May 26, 2016

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

  • Guest
    Reply
    |
    May 26, 2016

    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!

  • Rob Ormond
    Reply
    |
    May 26, 2016

    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.

  • Admin
    Chris Waters
    Reply
    |
    May 26, 2016

    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.

  • Guest
    Reply
    |
    May 24, 2016

    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!

  • Rob Ormond
    Reply
    |
    Feb 24, 2016

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

  • Guest
    Reply
    |
    Feb 24, 2016

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

  • Load older comments
  • +42
31 MERGED

When moving a JIRA issue from a linked fixVersion to another linked fixVersion, update Aha!'s release

Merged
In the mapping: Feature -> User Story If you create a new user story in a fixVersion that's linked to an Aha! release, Aha! reflects a new feature. If you move a user story from one linked fixVersion to another linked fixVersion it is not cha...
Suzanne Vaughan over 8 years ago in Jira 5 Shipped
9 MERGED

Jira updating fix version

Merged
It would be fantastic if you could allow Jira to push through updates on fix version to Aha!. I was discussing this briefly with your support team and they mentioned that the goal is that Project Managers are managing releases through Aha!. Howeve...
Guest almost 7 years ago in Jira 0 Shipped