Child pages
  • Mapping Jira Resolution when using Azure DevOps Scrum process template

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

Prerequisites

Overview

Scrum default process template in Azure DevOps only has Reason field for all known item types. State Done in Azure has only one Reason value Work finished. State Removed has one universal state Removed from the backlog for each known item type except Bug. It is enough to set up a single sync profile to handle all work item types.

If you would like to use Not a Bug, Duplicate resolutions for Bug (or for other work item types), enable resolution screen as described in Customize Jira to allow Resolution mapping

If screen is not enabled a warning in logs during transition to final state will appear:

Code Block
WARN SpartezSoftware.Synchronizer.Services.JiraIssueTransitionerService - Jira’s issue does not contain 'resolution' field. It could have been hidden from Jira screens.

How

Workflow mapping

Recommended workflow mapping for three statuses in Jira while having seven in Azure (all states below Done and Removed can be set by preferences, statuses Done ↔︎ Done/Removed is recommended for this guide)

Image Added

Resolution field mapping

Having above workflow mapping we can set mapping for Resolution <- Reason field mapping. Please notice this mapping unidirectional. In Jira we have one Done status which maps to Done state in Azure. There is only one Reason for marking work item as Done in Azure - Work finished. Anything else is forbidden in default Scrum process.

From Azure to Jira it is possible to map different resolution field being agnostic to state and status. If state is moved to Removed or Done in Azure it is transforming Jira issue to status Done. And depending on the Reason we can set different resolution thanks to mapping like below

Image Added

Attachments
patterns*.json