Mapping options

Learn about the various ways to map Avion entities to Jira entities.

When it comes to syncing with Jira, Avion has a large number of potential configurations available. In fact, there are so many that even we sometimes forget about a combination!

The configuration you choose should start with your goal. Ask yourself what the story map represents to you and your team. Then try to think about where the data from Avion would best sit inside Jira.

Sometimes it's hard to visualise this, so here is a table of the available options that might help.

Avion	Jira Cloud
Journey	Epic or custom field
Step	Epic or custom field
Story	Any issue type, including epics (not subtask)
Story size	System field or custom field²
Release	Epic or fix version or custom field¹

Bear in mind that if Avion journeys are mapped to Jira epics, no other Avion type will be able to map to epics. So it's important to think about this choice.

🆕 Multiple issue types for stories

A relatively new option that we've added is the ability to choose a subset of Jira issue types that you can push Avion stories too. This subset can even include epics, if they're not mapped elsewhere.

For instance, you could select three potential issue types for Avion stories:

With the above setup, you will see the ability to change the issue type of a story before it's pushed to Jira:

Be aware that once pushed, the issue type can't be changed.

Workflow and mapping ideas

Here are some ideas that might spark your imagination.

♟ Strategic planning

Use the story map to plan the big picture of your product across multiple teams. Your backbone will represent the high-level experience of your customers and stories are large chunks of work that are highly valuable to users and also contribute to your business goals.

Releases are made up of several stories and will help align around the actual delivery and deployment of the features.

Mappings

• Backbone → none

• Releases → fix versions

• Stories → Epics

👨‍💻 Granular delivery planning

Use the story map to plan a single team's product area. Your backbone will represent a highly accurate flow of the user's experience in the product. Releases will represent collections of stories that make up a big chunk of value to users. In the beginning, your MVP might be a single release.

Stories are a granular way to track all the development tasks and bugs to be fixed in the release.

Mappings

• Backbone → none

• Releases → Epics

• Stories → Stories, Bugs, Tasks, Enablers

⚙️ Process-driven planning

Use the story map to map out your typical development process. Your backbone will represent the flow of tasks that the team need to take. For instance, your steps might read:

• IaC scripting → Cloud install → Cloud deployment → Customer handover

Your stories will be tasks to be completed in each step. Releases can be used to split the work between different teams or team members.

Mappings

• Backbone → steps to epics

• Releases → none

• Stories → Tasks