Automation can be a powerful tool to leverage within a scrum team. Atlassian’s Jira automation can be used in a myriad of ways to keep things organized and reduce the time-cost of manually making associations or status changes within the Jira.
This is a link to Atlassian’s documentation on automation: https://www.atlassian.com/software/jira/guides/expand-jira/automation
Let’s take a look at three common automation types that can be incredibly useful to a team:
Updating the Fix Version (Release Version) of tickets linked to an Epic
Epics are deemed the highest in the hierarchy chain for Jira. In many cases, teams will associate Epics to a correlating version (or versions). Enabling an automated rule to update all “children” tickets which are linked to a given Epic, via the Epic Link field, is a major time saver! This type of automation is also a critical way of ensuring tickets don’t get lost in the shuffle.
Rather than passing off the administrative responsibilities of associating epics to other ticket types throughout the course of a release; a reduction in cost can be realized by enforcing this type of automation.
2. Setting the Resolution Status of a Ticket
Another handy automation to configure is to have the “resolution” of a ticket marked to a specified status upon completion. This can assist at completion of a specific group of tickets (such as a release) to ensure that items in a given state are associated with a correlating resolution status.
In the example to the left, items moved to the Done or Accepted state (for a group of workflows) will have the resolution field set to a given/defined status. This can be repeated, for other workflow-end statuses as desired.
3. Set the “Summary” and “Epic Name” fields as the same
When it pertains to an epic, the Summary and Epic Name fields are not the same — and in many cases are both required by default. This can lead to issues when querying by one or the other.
For example: If I created a new epic ticket type, as part of a large project, with the Summary of: “Pittsburgh Steelers” & then typed the Epic Name as “Pitsburgh Steelers”, one could have a very unpleasant time trying to find the epic by querying the text — Epics are displayed using the name, and in this case, the name and Summary don’t match.
The automation example to the left shows how to remedy the issue of a mismatched summary and epic name.
4. Set the start date to when development begins
The example to the left is a blanket automation, affecting all issues of any project specified in its details. In this case, any ticket moved to a development stage has the Start date field cleared (assuming there may ave been something populating the field before if the item had been paused) Then the Start date field is re-populated using the following Jira smart value for the date of development starting in the automation: {{now.plusDays(0)}}
This automation is particularly useful for observe statuses/goals (i.e. on the Jira “Plans” Gantt charts)
5. Set the due date to the end of the active sprint
While there are many other uses for the automation feature within Jira, one last example to consider, specific to teams who are “sprinting” or using a scrum board, is where the due date of an issue can be set to the end of an active sprint using the following Jira smart value in the automation: {{issue.Sprint.endDate.jiraDate}}
This means that the issue that was allocated, or pulled-in, to an active sprint should be technically deemed due at the end of that sprint (as part of the sprint’s work commitment).
This field can be reset, or left as the sprints end date, if it doesn’t get completed in the sprint it was initially part of.
Like the start date automation above, this automation is particularly useful for observe statuses/goals (i.e. on the Jira “Plans” Gantt charts); as well as to review missed sprint commitments.