How I worked only 2 hours in the last 3 weeks - Jira Automation
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.
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.
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.
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.
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
TODOstate while work is in progress
- Finished but not closed epics
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.
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:
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
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
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:
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 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.
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.