Jira Automation — A Tool to improve Individuals and Interactions — Part 2

Hello, my name is Fred Deichler and I’m a Scrum Master at Field Nation. This article is Part 2 of my efforts to expand our automation that supports asynchronous communication.

If you have not already done so, you can catch up on the story of how I got to this point in Part 1 or you can forge ahead.

During Part 1 I discussed how Jira Automation could improve our workflow and provided 4 examples of how we were doing it. This article outlines 4 additional rules that show how an Incoming Slack Webhook can take asynchronous communication to the next level.

The rules in this article are

1. Issue added to current Sprint
2. Priority in Jira has been escalated
3. Bug Created by the Triage team has been Updated
4. Daily Major Bug Reminder

To start your Jira/Slack integration you 1st need to configure an incoming Webhook

1. Issue added to current Sprint

The problem this rule is trying to solve is awareness and transparency of when an individual is adding a ticket to a Sprint.

Utilizing the newly created incoming webhook (which can be used for every Jira Automation rule, as long as we specify the location in the Channel or user box) we are able to push the important information to the slack channel that is most relevant.

This is our 1st example of smart values, which allow us to serve the information we desire. As you see below we see

• {{initiator.displayName}} = the individual user who performed the Jira change
• {{issueType.name}} = the issue type
• <https://company.atlassian.net/browse/{{issue.key}}|{{issue.key}} {{issue.summary}}> = this creates a clickable link with the issue summary in the link (be sure to substitute your Jira instance in place of company.atlassian.net)
• {{issue.priority.name}} = the priority of the issue
• {{issue.fields.reporter.displayName}} = the creator of the issue

2. Priority in Jira has been Escalated

The problem this rule is attempting to solve is an alert to the responsible team when the priority of an issue is raised from a Minor status to a Major status.

Because this is a Major issue we add a bit more information to the post to Slack.

• {{#issue.labels}}{{.}}, {{/}} = this joins any labels that are on the Jira ticket with a comma
• {{issue.description.abbreviate(300)}} = this captures the first 300 characters of the description, it is important that we abbreviate this as failure to do so can (and did) cause a very large message to be posted to Slack
• {{issue.comments.last.body.abbreviate(300)}} = the last comment posted to the ticket (also abbreviated)

Those with a keen eye will have noticed that this rule actually sends 2 Slack messages and that is because Field Nation has a Triage team that would like to be alerted if one of the tickets created by them is escalated in priority. Discussions with our Triage team helped me create a shorter message that was more relevant to them.

3. Bug Created by the Triage team has been Updated

The ability to alert our Triage team on a priority escalation caused another rule to be desired.

This rule alerts the Triage team if a ticket created by a Triage team member has started its journey through the development process. An important alert as it eliminates the need for the Triage team to explicitly follow-up on each ticket they create and the team does not have to rely on subscribing to each ticket in Jira and watch their email.

• {{changelog.status.fromString}} = the prior status
• {{issue.status.name}} = the new status

And, how does it look in reality?

4. Daily Major Bug Reminder

With all the tickets flying around, sometimes bugs that are classified as Major don’t get noticed right away. I had a task on my calendar every morning to check for new Major Bugs that were not in a Sprint and I said to myself

Can Jira & Slack do this for me?

This rule uses a Schedule and a Cron expression to execute.

At 7:45 UTC the following JQL runs and executes for each positive result and sends a Slack message to the appropriate channel to alert the team.

(project = Ecosystems and type = bug and status = open) and priority in (Major,Blocker,Critical) and Sprint is EMPTY

With the rule in place, I couldn’t wait until the Cron job ran to validate its functionality, so I found that a team had 2 tickets that were Major and not in a Sprint.

So, there are 4 more rules to improve Asyncrounous Communication using the automation tools provided by Jira Automation and Slack.

I have 1 more rule that I’m going to share with you in Part 3 which takes demonstrated how all these rules can work together to quickly address production issues in a seamless fashion.

Join me for Part 3