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
  • Likely 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. 

     

    Sudipta

    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 1, 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.