Unlock the Power of Jira Automation
Reduce your overhead. Increase your accountability
Jira can be hard to set up and easy to mess up, but if used right, it helps everyone see and agree on work without slowing things down. One tool in your Jira toolbelt is its Automation feature.
Want to be notified any time an event occurs? Automation.
Want to check certain conditions periodically? Automation.
The interface
TL;DR: Just go explore it.
Jira does a solid job giving you suggestions. You can see it when you click into automation within a given project:
Additionally, Jira has a respectable tour of the feature once you click “Create Rule.” It will walk you through the core concepts within an Automation:
If this is all new to you, I recommend you follow the Atlassian tour first. Check out this link (as of 3/26/2024) for the latest.
Where Jira’s guide falls short
Where their guide falls short is digging deeper into the scheduled types of tasks.
Scheduled automation is available as a type of “When” trigger:
Scheduled Automation Use Cases
Tickets past their due date
Let’s say that you want to message any team members assigned to a ticket that is past its due date. You could use automation in several ways including notifying a channel or sending an email to that user and the manager of the team. You could even add a comment on the ticket to mention that the notification went out.
Stale Tickets
Let’s say your team has a recurring issue with tickets getting stuck in code review. You could add automation for Tuesday and Thursday mornings to check if any ticket has been in code review for over 24 hours without being picked up. This could then send a message to a Slack channel notifying the team of the stale ticket that needs attention.
End of sprint report
Let’s say that you run weekly sprints and your team has found it useful on Friday mornings to know which remaining tickets are still open at the start of the last day of the sprint. You could use automation to send a message to your Slack channel of all remaining open tickets as well as who is assigned to encourage swarming at the end of the sprint.
Ok - so let’s set one of these up! Stale Tickets
First, get your JQL Correct. Probably something like this:
project="Practice Board" and status="Code Review" and assignee is EMPTY and updatedDate < -2d
Set up your new role and copy-paste the JQL into a new scheduled configuration:
Make sure you uncheck the “only include issues that have changed since the last time this rule executed” so that you make sure stale tickets continuously show up.
Use the “Send Slack message” feature. Note: you’ll need to configure a Slack webhook.
For the Message, use something like this:
Stale Code Review - <{{issue.url}}|{{issue.key}}> - *{{issue.fields.summary}}**Reporter:* {{issue.fields.reporter.displayName}} | *Last Updated:* {{issue.updated}}
Save the run and then click Run to test that it is working correctly! Tip: If you don’t have any stale tickets, change the JQL to something that you know will return at least one ticket.
That’s it! Your team is now notified when unassigned tickets sit in code review for more than two days.
Best Practices
If possible, you should mention someone in the message.
If people don’t pay attention to your message, adjust it or get rid of it. Noise is worse than no message at all.
For the stale ticket example above, don’t forget about Jira’s Control Chart. You can use this to review a longer period and see if a particular status tends to take too long.
That’s it! What kind of automation do you have? Please share!