Mapping options
Learn about the various ways to map Avion entities to Jira entities.
Last updated
Learn about the various ways to map Avion entities to Jira entities.
Last updated
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.
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.
Here are some ideas that might spark your imagination.
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
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
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
