The integration between Aha! and Jira is one of our most popular, for good reason.

Aha! handles the "why" and "what" — your strategic goals and the work you need to accomplish to reach those goals. Jira handles the "how," as the platform engineering teams use to complete the work you've defined. With a robust two-way integration between the two tools, the work you send to engineering teams comes with full strategic context, and the updates you get back inform how you are progressing.

When you first configure the integration, though, you may have questions about which Aha! record types should link to which Jira record types. In this article, we will discuss some of the most common ways to link the two tools.

Note: This article refers to releases and features. Depending on your workspace type, you may see "schedules" and “activities" in your workspace. Regardless of your record terminology, you can still map Aha! and Jira records to each other the same way.

Click any of the following links to skip ahead:

How to think about mappings

This integration is intentionally flexible – you can map Aha! and Jira record types together in a variety of equally valid ways. It's important, then, to think intentionally about how you want Aha! and Jira to work together.

To get started, consider these questions:

  • How are you organizing work in Jira today?

  • In Aha!, what level of that work do you need visibility into?

As a best practice, we recommend that you define work in Aha! first — typically in releases, features, and requirements — and send it to Jira when you are ready for your engineering team to begin executing on it.

Let's walk through three common ways to connect Aha! and Jira. To model your integration after any of these options, navigate to Settings ⚙️ → Workspace → Integrations, select or create a Jira integration, and move to the Mappings step. You will need to be a workspace owner to do this.

Top

Option 1: Features to epics

Aha!

Jira

Feature

Epic

Requirement

Story

Choose this option if:

  • Your work in Jira is organized into epics and stories, and in Aha! you need visibility into the stories.

  • All Jira stories have associated epics.

  • Jira epics and their associated stories are completed in the same release.

  • You do not need to see detail beyond the story level in Aha!, even if Jira stories have been broken down further.

Top

Option 2: Aha! epics to Jira epics

Aha!

Jira

Epic

Epic

Feature

Story

Requirement

Sub-task

Note: Epics provide another layer of organization above features. They are disabled by default when you first create an Aha! account. To enable them, navigate to to Settings ⚙️→ Workspace → Configure → Epics.

Choose this option if:

  • Your work in Jira is organized into epic, story and sub-task and in Aha! you need visibility to that level.

  • Your team in Aha! is in charge of breaking down stories into smaller units of work.

  • Jira epics are completed iteratively, with associated stories delivered over multiple releases.

  • You want to include sub-tasks in your Aha! roadmaps.

Top

Option 3: Features to stories/tasks

Aha!

Jira

Epic

Epic

Feature

Story/Task

Note: Epics provide another layer of organization above features. They are disabled by default when you first create an Aha! account. To enable them, navigate to to Settings ⚙️→ Workspace → Configure → Epics.

Choose this option if:

  • Your work in Jira is organized into epics and stories, and in Aha! you need visibility into the stories.

  • Some Jira stories are not associated with an epic.

  • Jira epics are completed iteratively, with associated stories delivered over multiple releases.

  • You may also define work in Jira using Tasks. In that case, this option works well if in Aha! you need visibility into Jira tasks, and some tasks are not associated with an epic.

Top

Mapping sub-tasks

Mapping Jira sub-tasks to an Aha! record type is an optional step. It makes the most sense if:

  • Your team in Aha! is in charge of breaking down stories into smaller units of work.

    Note: If the engineers working in Jira are responsible for breaking down stories into further sub-tasks, then generally you can leave sub-tasks unmapped in the integration. Jira sub-tasks in this situation are usually development-related records that you do not need Aha! visibility into.

  • You want to include sub-tasks in your Aha! roadmaps.

Top

Mapping releases

Aha! releases are generally mapped to Jira versions. Mapping them is an optional step that comes down to whether your use of an Aha! release matches with the engineering team's use of Jira versions.

For example, a product management team in Aha! may organize work into releases by thematic update, while an engineering team in Jira may organize work into versions around actual product versions. In that situation, it would not make sense to map Aha! releases to Jira versions.

If you do not choose to map releases to versions, you can still include the Jira fix version field in your field mappings. Map the Jira field to a custom field added to the Aha! feature layout to include that level of context in your features.

Top

Mapping multiple Jira versions to one Aha! release

In Aha!, releases are containers for work organized around release dates, when you deliver a Complete Product Experience to your users. But in Jira, you may need to split your release into multiple versions, tracking increments or developer releases, or sprints.

Thanks to custom fields, you can map multiple Jira versions to one Aha! release. The Jira records will have two related fields: one to track the Aha! release (such as a go-to-market version) and one to track the Jira increment (such as a code deployment version).

Note: In this example, we will use a custom field to track Aha! go-to-market versions, and the existing Jira FixVersion field to track code deploys, but you can of course track these fields the other way around.

  • Go-to-market version:

    • Create a custom field in Jira using a version field type (Version picker (single version), for example).

    • Map the Jira fix version to an Aha! custom field on the epic/feature.

  • Code deployment version:

    • Continue using Jira FixVersions to represent the code deployment versions.

    • In the integration configuration, use the custom version field for go-to-market version in the Links to relationship.

There are a few things to consider with this approach:

  • Each Jira record would require both a fix version and a go-to-market version.

  • The Jira Releases screen may cause confusion because the go-to-market release using the custom Version field will not include any issues.

  • If you import releases to Aha! from Jira, then the field you use to track Jira code deployments may be included — and you may want to exclude it.

  • Aha! users will need to ignore certain release records importing from Jira. For example, when a new FixVersion is created in Jira, it will be an import candidate for Aha!, but those Jira issues might already exist in your Aha! release.

Top

Record relationship links

While setting up your integration, you can define a Links to relationship in the Mappings step. This associates Aha! record types with each other. For example, if releases are your top record type, and features are the second, you could link features to a release's Fix versions. As a release in Aha! updates, it will update the features associated with it as well.

The order in which you map record types to each other matters, because it establishes fields are available to you in these Links to relationships.

Top

Status mappings

When you map two record types to each other, their statuses will also be mapped to each other. You can review and adjust these status mappings by clicking Configure by a record type in the Mappings step of the integration setup.

Top

Aha! Roadmaps
Strategic roadmaps
Integrations
Jira integration troubleshooting
      Aha! Ideas
      Announcements
      © 2020 Aha! Labs Inc.All rights reserved