The JIRA integration is our most robust integration and offers advanced functionality. This document explains what that functionality is and how it works. For information on the basic functionality of the JIRA integration, please refer to the Integrating with JIRA document.
Issues created in JIRA automatically populate into Aha!
Aha!'s integration with JIRA is two-way. This means that once a link is established between Aha! feature/requirement and JIRA issues, updates are bi-directional and automatic. Links are established one of two ways:
- You send features to JIRA from Aha!
- You import backlog items from JIRA to Aha!
Aha! is where you plan and vet your releases and features. However, once you send features to JIRA, they may be split into additional user stories or sub-tasks. It's also possible that they -- and existing issues in JIRA -- may be moved into a version or user story already linked to Aha! This is especially common when using sub-tasks in JIRA or mapping Aha! features to JIRA epics. When this occurs and the issue in JIRA gets created in Aha!, the JIRA issue will update to include the Aha! Reference ID.
The two-way integration with JIRA supports two workflows where items in JIRA automatically populate back into Aha!
- If a new issue is created in JIRA and linked to an existing Aha!-linked parent item (mapped to Release or Feature), it will automatically be created in Aha!
- If an existing JIRA issue is moved under an existing Aha!-linked parent item (mapped to Release or Feature), it will also be automatically created in Aha!
Note: Common parent items are: Fix Version, Epic (if mapped to Features), User Story (if mapped to Features). Any issue in JIRA that is mapped to Features in Aha! is potentially a parent item.
- An existing JIRA issue is moved to a Fix Version associated with an Aha! Release, a feature will automatically be created in Aha! under that release.
- Aha! Features = JIRA User Stories and Aha! Requirements = JIRA Sub-tasks; a feature is sent to JIRA, then a sub-task is added to the user story in JIRA and a requirement is added to the feature in Aha! automatically.
- Aha! Features = JIRA Epics and Requirements = JIRA User Stories; Stories created in JIRA and associated with the Epic will populate as a requirement under the feature in Aha!
Customize what issues get created from JIRA to Aha!
In some cases, you may not want all issues to be created in Aha! automatically. You can manage what automatically gets created in Aha! through a couple of different settings in the JIRA integration configuration page or by directly editing the webhook in JIRA. There are two common scenarios:
A) You don't want Aha! to create any features automatically from issues added in JIRA.
- Check the "Don't auto import" checkbox in the integration configuration page to prevent Aha! from automatically importing issues that are related to an issue already linked to Aha!
- Alternative solution: Modify your existing webhook and disable the "Issue Created" event. This will prevent JIRA from notifying Aha! about new issues.
B) You want to limit which issues are converted to features.
- Check the "Only auto import mapped issue types" checkbox in the integration configuration page to prevent Aha! from automatically importing issue types that are not mapped to features or requirements. Note: if this is not checked, unmapped issue types are automatically imported as features.
- If you wish to be able to import issue types beyond the integration mapping for features, uncheck the "Only auto import mapped issue types checkbox" and edit the webhook instead. Add a JQL query to the webhook that will only allow the issue types that you want to be automatically created in Aha!. Example: issuetype in (Epic, "User Story", Sub-task)
This will cause JIRA to only notify Aha! of new issues that match your criteria.
For help with JQL see the bottom section in Import features from JIRA.
Aha! Releases and JIRA Fix Versions
An entire release in Aha! can be sent to JIRA via the Release action item Send features to JIRA. Aha! maps a release to a JIRA Fix Version. There is an option in the Aha! integration configuration to disable this if you do not want to have Aha! create JIRA Fix Versions or update the FixVersion field. This can be desirable if the development team is referencing multiple FixVersions per feature in JIRA, as otherwise Aha! will overwrite the multiple FixVersion references on a feature in JIRA and update FixVersion with the feature's Aha! release.
- When a release is first sent to JIRA, a corresponding Fix Version record will be created in JIRA. The name and date on the Fix Version will be based on the Aha! release.
- Each time the release is sent to JIRA again, the name and release date will be updated to match the release in Aha! Changes to the Fix Version in JIRA will not be reflected back in Aha!
- Each feature in the release which has a corresponding issue in JIRA will have its version field set to the Fix Version that was created. When features are moved between releases in Aha! the version field in JIRA will be updated to match.
- If a Fix Version already exists in JIRA with the same name as the Aha! release, then a new Fix Version will not be created. A link between the Aha! release and the JIRA Fix Version will be created.
Aha! never deletes issues from JIRA. Any feature or requirement that is deleted from Aha! will not cause deletions in JIRA. Likewise, deleted items in JIRA will not cause items in Aha! to be deleted.
The same is true for attachments. If an attachment is deleted in Aha! the corresponding attachment in JIRA is not deleted. Conversely, if attachments are deleted in JIRA, they will not be deleted in Aha!
This is to protect against inadvertently deleting another team's work.
Collaboration between the product and development team is essential. The JIRA integration supports two-way updates of comments where comments added in either application will be reflected back and forth. However, due to API limitations, they will show up as written by the user with which the integration was configured.
Comments on a feature in Aha! are not sent over initially. Once the feature has been sent to JIRA, any future comments will be updated on either end.
You can assign owners to both features and requirements in Aha! Assignees can be Product Owners, Contributors, Reviewers, or Viewers. If every user in JIRA is also in Aha! you can map assignees between the two.
Assignees are mapped based on their email address. They must be using the same email address in both systems for the mapping to happen. If a user with the same email address is not found in the other system, then no change to the assignee is made (for data flowing in either direction).
Note: When features or requirements are sent to JIRA, the reporter field will be set to the JIRA user who has the same email address as the Aha! user who originally created the feature or requirement.
Estimates and Time Tracking
The integration supports feature/requirement estimates as well as time tracking. Changes to the remaining time estimate and logged work in JIRA will be reflected in Aha! if you have capacity planning enabled. For this integration, Aha! assumes that the default time tracking value of minutes is configured in JIRA.
If you are using story points for estimation and JIRA Agile is enabled in your JIRA account, then the point estimates will be synced with JIRA Agile. For this to work, you may need to add the Story Points custom field in JIRA to the default screen so that Aha! can update it.
Sometimes, changes are made to fields in JIRA that are not mapped to Aha! In this case, a comment will be added in Aha!
Once Aha! records are linked to JIRA records, changes in the structure of the records will not be synced (e.g. changing a feature to be a requirement or changing a requirement to be a feature).