address. Gaston Geenslaan 11 B4, 3001 Leuven
All Insights

Jira Automation - How I only worked 2 hours in the last 3 weeks

In this blog post, we will show how you can eliminate the annoying manual work of story management in Jira by using the Automation power that Jira supplies at the professional tier level.

Written by
Benjamin Dendas
Full-stack Developer

As a full-time Scrum Master, I dedicate myself to helping teams work more efficiently. As a part of that, I have been looking into automation, especially since we re-evaluated the tool stack we use at Craftworkz. My job was to look into Jira. Yikes.

That moment people come for you for knowledge, but you’re actually just clicking things.

Even though this was not my preferred tool, this learning opportunity did align perfectly with my consultancy project. We were about to move away from DevOps (to be honest: because it sucked) to another project management tool. I'm not saying that everyone was happy about that change, but it was for the better. I mean, come on, DevOps, really?

Is Jira better? No, it is not. On tons of occasions, Jira is just so complex that you nearly need a degree for it. Oh wait, true, they actually have that here.

To make a good case for why we should move to Jira, I revised the tool quite in-depth. I noticed that Jira changed a lot compared to when I used it extensively. One of the things I didn't notice back then was their extensive automation section. Digging deeper into automation, you see that it solves some of the most annoying work that comes with Jira and software development administration in general.

Automation rules

Jira offers automation rules that you can set up in a project. These automation rules will trigger when certain events happen within the project, resulting in an expected state.

As a user, you have two options. Either you can start building your own automation rules, or you can use the search feature to look through the library of already available rules.

Picture of the automation library in JIRA
Jira Automation library

Personally, one of the most annoying things about story and epic management is the manual opening and closing administration to show progress on a high level. With automation rules like when all stories are completed → then close the epic, we eliminate that frustration.

After working on multiple projects, I see the same things coming back when it comes to the management of tickets:

  • Stories in progress but assigned to no one
  • Epic’s in TODO state while work is in progress
  • Finished but not closed epics

Updating boards

To show progress transparently at any moment, we update boards. Like all humans, developers are weird creatures, and if they can take shortcuts, they will. Why move a story to in progress when you could instantly transfer it to done and reach the same result, right?

There's one automation rule where you can assign yourself to a story and the ticket is moved to in progress automatically: when a story is transitioned -> then automatically assign, which assigns the person based on the account that moved the story. It might not seem like a big deal, but it saves the developer a few clicks every time they move stories.

Picture of the automation rule to assign issue to transitioner
Automation rule to assign a user to a story when they move the issue to in progress

Define custom automation rules

When you work in a corporation with multiple teams, more complex Jira boards can facilitate the software delivery lifecycle flows. For example, I have QA lanes on my boards - not because I like them, but because every ticket needs to go through a tester that validates the implementation on a functional level. When a ticket moves to the QA lane after a code review, we automatically mail a set of users.

In Jira, we do this by the following rule:

Picture of the automation rule to mail the QA Team
Automation Rule to mail the QA team

We have an unwritten policy to test only the story when the main ticket contains all relevant information. Subtasks can go straight to done as they have the same information but split up.

When the issue is not a subtask, we validate if the QA assignee is not empty. If that is the case, we take some parameters from the issue itself and send the mail to the QA assignee.

Moving parent to in progress when moving substory

Not long ago, I noticed that the developers moved the sub-stories that we made. Cool, until it became clear that the actual story itself was in the Todo column. Not cool.

Channeling my inner coach, I notified my team that they should put the story itself in progress. This may seem not very pleasant for them, but it makes sure that I can keep an eye on the time required for the complete story to go from todo to done.

After sharing that insight with my team, I got another brilliant insight. 😉 (Yes, I just gave myself a pat on the back, deal with it). I could write an automation rule so a situation like this couldn't occur anymore in the future. The rule looks like this:

Picture of the automation rule to move the parent story to in progress when the child story moves to in progress
Jira Automation rule to move parent to in progress when substory moves to in progress.

Rule executions

Jira will show you the number of times a rule is triggered in the last 30 days. This is especially useful when you want to eliminate automation rules that aren't very useful and show you how much actions and time you have saved by not needing to do them manually.

For reference, we have three active projects (two sprint-based, one kanban) where all those rules run actively. We have about 15-20 people involved in Jira, and our subscription plan gives us 1000 executions/user every month.

It is best to specify the rule as narrow as possible. The top rule with the most executions is the When support ticket is made, assign to PO for investigation rule.

This rule is in place as our PO needs to validate whether it is a valid support ticket or another sneaky change request.

The bad thing about this rule is that it executes every time we make a new ticket. The rule contains a check for the ticket type. Depending on the check, it will trigger an event or not. This rule will always be one of the top rules for our automation setup.

List of executions for automation rules within our project
Automation rule executions/month

List of automation rules active

As the last part of this blog post, I'd like to share the automation rules that are currently active within our projects.

The rules that we show here are configured as global rules within Jira. A global automation rule applies to every board that exists within the organization.

We are currently still looking into other automation rules that we could include to make the developers' lives even more straightforward.

Copy labels from parent to subtask

Not all teams within the organization are cross-functional teams. To organize the board by targeting specific team stories, we use the Labels field in Jira. We show a limited board view for stories with custom filters on the board level. As we don't want to add all those filters for every substory we create, we have written an automation rule that adds them for us.

Move sub-stories when parent moves to new lane (starting from in progress)

When a ticket with sub-stories moves from in progress to another lane, we will automatically move all sub-stories to the same lane.

When a commit is made, move issue to in progress

This is the first move to eliminate manual Jira work as much as possible. Our developers use certain conventions when they commit code. With our git repositories linked with Jira, we see the commits related to a ticket and use automation rules to automatically move the story to progress if the developer hasn't done it yet.

When all stories are completed, close the epic

Open epics are one of the things that I see in most backlogs, and this automation rule closes them automatically to keep the backlog clean.

When an issue is transitioned, automatically assign the transitioner

This one ensures that there's always a person assigned to a ticket. This rule occurred because developers tend to forget to assign themselves to a ticket, resulting in the Scrum Master looking at the board and having no idea what person x is doing.

We do have one exception in place for this rule. It does not activate when the PO or SM moves an issue to progress, as we update the board but don't pick up work ourselves.

Closing thoughts

With all the automation rules in place right now, my workload has decreased significantly during standups as I don't need to assign people to stories anymore.

Moreover, these automation steps won't make the Scrum Master obsolete at all, as it enables them to put more time and effort into solving more complex issues and look at the possible improvements that could be hanging around that are not JIRA-related.

Written by
Benjamin Dendas
Full-stack Developer

Subscribe to our newsletter

Raccoons NV (Craftworkz NV, Oswald AI NV, Brainjar NV, Wheelhouse NV, TPO Agency NV and Edgise NV are all part of Raccoons) is committed to protecting and respecting your privacy, and we’ll only use your personal information to administer your account and to provide the products and services you requested from us. From time to time, we would like to contact you about our products and services, as well as other content that may be of interest to you. If you consent to us contacting you for this purpose, please tick below:

By submitting this form, you agree to our privacy policy.

In order to provide you the content requested, we need to store and process your personal data. If you consent to us storing your personal data for this purpose, please tick the checkbox below.

More blog articles that can inspire you

what we do


address. Gaston Geenslaan 11 B4, 3001 Leuven