Jira issue mapping

Mapping Jira workflows and issue types to Swarmia

No two teams are the same, so Swarmia supports various Jira issue types and custom workflows, and allow each team to configure work that's relevant to them.

You should start by mapping the issue types and workflow for your organization. After this is done, you can proceed to map the issues that belong to each team. Doing all this allows you to analyze work grouped by issue on the Work Log, as well as analyze the issue flow insights (eg. cycle time for Stories).

Mapping issue types

⚠️ Note: Jira issue type mapping applies to the whole organization.

While your issue tracker is probably configured with a variety of issues and workflows, Swarmia is focused on giving you the facts about your flow. We cut through the complexity in your issue tracker and divide work into four simple categories:

  • Epics are large bodies of work like projects from the roadmap that can span long timeframes and typically involve multiple teams

  • Stories are smaller bodies of work that usually add a direct customer value like a new feature and are important for the team to stay on top of

  • Tasks are planned technical or administrative work that do not directly add customer value but are still important for the team to track and accomplish

  • Bugs are usually unplanned work that result from defects in production or other unexpected outcomes that must be addressed and tracked

By default, Swarmia uses the corresponding Jira issue types as Swarmia issue types (ie. we include into Epics everything that's an Epic on Jira).

You can configure how this mapping is done for your organization, eg. to include several issue types or more complex rules.

  1. Navigate to Jira settings
  2. Configure each issue type in the Issue types section. Often, this will simply be attaching each Jira issue type in use to the available issue types. Remember to Save your selection.

💁‍♀️ Mapping subtasks is not necessary. Swarmia recognizes Jira hierarchies, so mapping subtasks is not required. For example, mapping a Pull Request to a Jira subtask means that it is also automatically mapped to its parent Story, Task and/or Epic in Swarmia.

Configuring issue types for an organization

Mapping the workflow

⚠️ Note: Jira workflow mapping applies to the whole organization.

Your team can have a complex Jira workflow with custom statuses. Swarmia groups work into four general statuses:

  • To Do: Issues that may be planned or specified, but not expected to be worked on by your team just yet
  • In Progress: Issues that your team is expected to be working on at the moment, even if they are currently blocked or otherwise inactive

  • Done: Issues that are completed, or closed, and that are not expected to be worked on anymore by your team
  • Won't Do: Issues that are canceled or otherwise won't be worked on anymore.

Mapping the workflow on Swarmia is a simple process of selecting a workflow step for each Jira status in use:

For each status, select the corresponding workflow states in your Jira configuration

Mapping team issue ownership

Many teams use a number of custom Jira projects and potentially are only interested in only a part of the work in multi-team projects. Team ownership mapping allows teams to see only the work that's relevant to them.

  • Navigate to Settings → Team → Issues
  • Select the Projects and other filtering criteria (eg. issue types and labels) to determine which issues you want to see for each team
  • Hit Save and enjoy the up-to-date Work Log grouped by the types of work you've just configured