Synchronize Jira Agile Objects in Squash TM
What It Does
Once the Xsquash4Jira plugin is correctly set up, Jira issues are automatically synced as requirements in Squash TM and updated on a regular basis. The synchronization repository as well as all the requirements it contains are created during the first update.
The synchronization is only one way, from Jira to Squash TM.
This part explains how these assets are organized in the Requirements workspace.
In Squash TM, synced requirements are the equivalent of Jira issues. In the requirements tree, their name is grayed out and preceded by this icon
This icon indicates that it is a synced requirement and also gives information on the synchronization status of the linked Jira issue using the following color code:
- green icon: the requirement is always updated via synchronization;
- yellow icon: the requirement is no longer updated via synchronization because the matching Jira issue is no longer in the synchronization perimeter defined in the plugin's configuration (for example, the Jira issue now has a status that is not in the filter chosen for the synchronization);
- red icon: the requirement is no longer updated via synchronization because the matching Jira issue was deleted in Jira or was moved to another Jira project (its key was modified);
- black icon: the ticket's synchronization status is unknown (for example, when the global synchronization has failed)
Synced requirements have 3 more details than native requirements:
- A hyperlink to the original Jira issue;
- The Jira issue's synchronization status that indicates if the requirement is still updated by synchronization and if the matching Jira issue is still in Jira;
- The Jira issue's synchronization status, which alerts the user if the communication between Squash TM and Jira is disrupted or if an error has occurred during the last update.
Modify, move and delete
Synced requirements can be modified in Squash TM. There are two behaviors depending on the field to be modified:
- it is a synchronized field (description, reference, or any other field with a mapping): modifications are erased with the next synhronization if the issue is updated in Jira
- it isn't a synchronized field: modifications are kept in Squash TM
'Approved' and 'Obsolete' statuses prevent requirements from modifications. As a result, when a requirement is modified with one of these statuses, it is not updated anymore. The status has to be manually set to 'Work in progress' or 'Under review' to enable again the requirement update.
Synchronized requirements can be moved in the requirements library. Again, several behaviors:
- the requirements are moved into the same project: they are still updated and stay or don't stay at their new location depending on the organization type (see Synchronized requirements organization)
- the requirements are moved into another project: they become native requirements in the target project and are recreated in the source project during the next synchronization
When deleting synchronized requirements in Squash TM:
- if the requirements are still in the synchronization perimeter: they are recreated with the next synchronization
- if the requirements are not in synchronization perimeter anymore: they are not recreated in Squash TM
Jira issues attachments are synchronized in Squash TM as links in the requirements description. They are the links to the attachments in Jira.
In Squash TM, the link between a sub-task and a user story is represented as a requirement hierarchy if the two requirements are in the same synchronization.
This link having a specific meaning in Jira, it is not recommended breaking it in order to have correct coverage indicators for the parent requirement.
It is possible to add a herarchy of native requirements under a synchronized requirement.
For example, a Jira issue could lead to several test requirements in Squash TM. These test requirements can be added under the synchronized requirement that matches this issue in Squash TM.
The target repository is the parent repository in which the Jira issues are synchronized. Depending on the synchronization type, repositories can be automatically created under the target repository.
Target repositories are also preceded by this icon and their color code is similar to the one of synced requirements:
- green icon: the synchronization of the target repository has succeeded and all the synced requirements it contains are updated via synchronization;
- yellow icon: the synchronization of the target repository has succeeded but it contains requirements that are no longer updated via synchronization because they are no longer in the synchronization perimeter or Jira anymore;
- red icon: the synchronization of the target repository has failed (for example, when the communication between Squash TM and. Jira is disrupted or if an error has occurred during the last update).
Move and delete
Target repositories can be moved in the requirement library:
- target repositories are moved in the same project: their synchronized requirements are still updated
- target repositories are moved in another projet: their synchronized requirements become native requirements in the destination project and the target repositories are recreated with the next synchronization in the original project
If the target repositories are deleted in Squash TM, they are recreated with the next synchronization.
Synchronized requirements organization
Scrum board synchronization
When synchronizing a scrum board, sprints are synchronized as folders in the requirements library and contain synchronized requirements corresponding to the Jira issues in the sprint.
Issues in the backlog are synchronized at the root of the target repository.
If an issue is moved in another sprint or in the backlog in Jira, it is automatically moved in the matching folder in Squash TM.
Accumulation of closed sprints in Jira leads to the creation of numerous sprint folders in Squash TM. To improve readability, it is possible to create one (or several) archive folders at the root of the target repository and move the closed sprints into it. In this archive folder, sprint folders can be organized by year, theme or else.
If the sprint organization is not relevant anymore, synchronized requirements can be moved anywhere in the same Squash project. The only restricion is to not delete the closed sprint folders, in order to prevent them from being recreated with the next synchronization.
It is recommended to move neither unfinished sprint folders, nor their content. Once the sprint and its issues are closed, archiving can be done in Squash.
Other synchronization types
For other synchronization types (Kanban boards, filters, JQL queries), requirements are created at the root of the target repository. The user is then free to organize synchronized requirements as he wants, as long as he is not moving them into another project, so they can still be updated.