RELATED IDEAS
Allow grandparent/child record relationships to automatically sync in development integrations
What is the challenge?
Currently, ADO can have a 3-tier record relationship (Epics > Features > PBIs)
Aha! only allows a parent-child relationship, not a grandparent-grandchild relationship
If I have an ADO Epic mapped to an Aha! release, this means that I have to move integrated grandchild PBIs to their grandparent release in Aha! manually as it's not associated with its parent's parent record
What is the impact?
Manually moving grandchild records to their grandparent Aha! record (i.e. release)
Grandchild records get out of sync with their grandparent release
Describe your idea.
Allow grandchild records to infer their grandparent relationship from their parent relationship (i.e. PBI (Aha! feature) gets added to the correct ADO Epic (Aha! release) based on its parent ADO feature (Aha! epic)
-
-
- +1
© 2026 Aha! Labs Inc.•All rights reserved
For some products, the releases are done at the Epic level in Azure DevOps, with the Feature in ADO being used to describe which feature is being built. Nested under the Features are the Product Backlog Items that outline the work that will take place for that feature. These are mapped in Aha! the following way:
ADO Epic --> Aha! Release
ADO Feature --> Aha! Epic
ADO Product Backlog Item --> Aha! Feature
The Features in ADO are used to group work together for the Product Owner (PO) to be able to better speak to the work being done. As an example, our last release contained 84 Product Backlog Items that rolled up into 5 Features. The PO is then able to have discussions on the feature level as needed, and not just the PBI level. Despite how that board is grouped, I want all features in Aha! (PBIs in ADO) to map to the correct release. The features map to the epic correctly, the epics map to the release correctly, and I would like the features to map to the releases correctly since its parent, the epic, is in the correct release.