Aha! + JIRA feature/story relationships (e.g. is blocked by, depends on) should match

If one feature depends on another, and you create that dependency in Aha!, it will not be reflected in JIRA currently. If Aha! and JIRA feature/story relationships were maintained back and forth, then we could create more realistic roadmaps and status reports.

  • Guest
  • Nov 3 2015
  • Planning to implement
Release time frame
  • Attach files
  • Guest commented
    November 17, 2015 14:11

    We also need this. If we go to the trouble of defining a relationship within Aha, we also need that to be reflected in Jira.

  • Sudipta Panda commented
    November 24, 2016 05:14

    This is so natural to think and add to product like Aha!. When an Integration happens from JIRA to Aha! it should automatically be done. Else there should be a Bulk Edit feature which should allow to maintain the Linked Feature in JIRA. Either way its deficient in achieving now. Kindly enable that in Aha! to make more sense. 



    SAP Ariba

  • Harrison Lynch commented
    March 30, 2017 02:48

    I wanted to try to bump this back up. It potentially solves one of the major JIRA limitations: that JIRA's hierarchy is much (too) flat relative to Aha. Basically, you can't create parent-child epics, which is severely limiting. If you could link the dependencies in Aha then have JIRA reflect these, it solves this somewhat.

  • Guest commented
    January 18, 2018 05:07

    Relationships among features are key. We have multiple JIRA projects with countless dependencies. To these days we have to maintain relationships in two different systems. Double work plus countless number of opportunities to make mistakes. It is amazing that one can see visual relationships between Aha! features, but it all goes away when moving to JIRA.

  • Guest commented
    January 25, 2018 17:07

    This is by far the most time consuming part of using Aha! and JIRA. I manage stories for four teams that build end-points, SDK, UILibs and FE dev. I have hundreds of dependencies across the entire stack and I cannot manage both in two different systems. I and up working in JIRA for relationships, but when I am planning in Aha! I need to keep going back and forth. Such a waste of time. Please implement this feature ASAP. Thank you.

  • Callum Rowe commented
    May 22, 2018 20:42

    We need this. I'm currently pushing features from Aha to four different JIRA projects. The feature isn't complete in our product until all 4 teams have delivered, so their view of the dependent work is absolutely required and it's a huge overhead having to work across Aha and JIRA to do that. Thanks!

  • Guest commented
    June 14, 2018 23:39

    I would be happy with just Aha! being able to accept/pull/copy the relationships of issues from Jira.

    To me it seems out of Aha!'s reach to push relationships to Jira.

  • Matt Brennan commented
    June 22, 2018 05:07

    This feature would be super helpful for my team.  From the product side of things, we implement tickets in Aha; then they are groomed in Jira to be completed by the engineers. Often this means that tickets are split into more than one, and dependencies change.  Currently, all the tickets exported from Aha, I have to recreate the dependencies in Jira, and vice versa if the engineers break tickets up or add additional tickets in Aha.  So far it's been a couple of hours of work for each major release we do.  Having this feature would be a huge time saver.

  • Surajit Kar commented
    July 25, 2018 11:42

    This is definitely a great feature to have  and would help visualize the thing more effectively 

  • Guest commented
    September 27, 2018 15:53

    This would be IMMENSELY helpful and is kind of the essential missing piece with the current Jira integration. 

  • Xavier Legrand commented
    October 01, 2018 12:00

    That would be awesome if we could get this feature. 

  • D O commented
    October 10, 2018 18:13

    I wanted to add a request for this type of functionality for all the reasons others have described (although I would like to see this for Azure DevOps/VSTS integrations). But the main reason I would like to see it is for mapping Non Functional Requirements to multiple user stories while keeping the NFRs as a single copy of data, instead of replicating the same requirements across user stories or features.

  • David Vins commented
    November 08, 2018 22:36

    This is going on 3+ years and is an important aspect that is lost when synchronizing between AHA <> JIRA. Is there any progress on this? Is it even in the works?

  • John commented
    10 Jan 01:09

    We definitely need this feature, it’s important for the engineering team to see dependencies in Jira so they can select work that will unblock other work. Also, oftentimes tickets for a body of work are created by the team in Jira, and being able to see these in aha to properly plan is invaluable. Needing to recreate these steps is time consuming and opens the possibility of error.

  • Nick Chan commented
    15 Jan 16:32

    Please add. This would take A LOT of operational/process overhead off of our global teams, which will require process workarounds and have weird rules that would be great to avoid by having system information parity instead. Thanks!

  • Arturo Orjuela commented
    30 Jan 15:07

    I have the same request, but for VSTS (Azure DevOps) <> AHA. 

  • Brendan Roy commented
    04 Feb 17:20

    This is also necessary as part of the TFS integration as well.

  • Eileen McEneaney commented
    21 Feb 19:33

    Lack of this feature causes major frustration for the Engineering dept which works out of Jira almost exclusively.  Please implement!

  • Guido Santo commented
    11 Jun 22:30

    This is a standing request since 2015 but I am hopeful as it is marked as "Planning to implement".

    If we could get at least an MVP this year that would be great. I understand that there is a level of complexity due to the various link types in Jira (not just the default links but also custom ones).

  • Krasimir Boev commented
    05 Aug 13:46

    We need both tools to be in sync at any time including any of the dependencies.