Deiser Blog | Atlassian | ITSM | DevOps | Agile at Scale | Cloud

Jira audits: Learn how to automate and diagnose large Jira instances

Written by Deiser | Sep 26, 2019 3:36:06 PM

Jira audits should be a periodical activity process for Jira enterprise instances that haven't had clear administration policies since day one; let's be honest. This also applies to all Jira instances. It's part of its maintenance process. In this simple step-by-step guide to consolidate Jira, we show how to make a semi-automated diagnosis of the situation that works for the most complex environments.


Jira audits are the solution to a common problem for any old instance of Jira unless those never had clear administration policies from day one. Time brings chaos and disarray, and that's why in this article, we’re going to show why that happens and how to make a semi-automated diagnosis of the situation that works for the most complex environments.

How many Atlassian customers started using Jira over ten years ago?

While it’s hard to give an accurate number, given that the company only started publishing its yearly financial reports after it went public in 2015, the volume is considerable and keeps growing.

Whenever you go into a startup or a corporation these days, you can almost assume the product teams will be using Jira to some extent -almost as much as you can see accountants running their balance sheets on Microsoft Excel.

When will we take Scott Adam's MBA? This is where wisdom meets sarcasm...

We just said Jira had become a facto standard. Becoming an industry standard also means more people are aware of the typical problems a user is likely to encounter… and, of course, these people need quality troubleshooting.

We’ve identified one of those typical problems on the path to consolidation, and we’d like to help with a proven method for diagnosing the health of large Jira instances. Hint: It all starts auditing in Jira.

Responses times of Jira

The following chart shows the response times of individual actions performed in the tool -from Jira Data Center 7.9, the "boards" performance has improved by nearly 30%.

Benchmark your instance's response time against Atlassian standards with this reference (Click here for more info)

With small teams, Jira works like a bullet. But as time goes by and more and more people and processes are thrown into the tool, performance takes a hit. Although Atlassian keeps revamping the product to be faster than yesterday, there are many factors still correlated with poor performance in Jira:

  •    The age of the instance.
  •    A large volume of issues (at least in the hundred thousand.)
  •    A large volume of projects with no transparent governance (i.e., when and how they should be archived.)
  •    Bottom-up, decentralized adoption of the tool.

Here are some signs of a corporate Jira crying for an audit:

  •    Different instances of Jira running on different versions.
  •    There is no clear picture of how many teams are on the tool.
  •    Nobody knows which projects are active and which are abandoned.
  •    The processes supported with Jira are not properly cataloged.
  •    Many Jira Admins with no one acting as coordinator.

We've seen this problem many times and under different disguises: Sometimes it’s a humongous instance migrating from Server to Data Center, sometimes it’s 22 instances of Jira that must be federated, sometimes it’s a merger. It doesn’t matter. The important thing is that there’s a way out.

...but you can stop it from happening

At Deiser, we have over 10 years of experience working with Atlassian customers, and we’ve encountered most of the situations listed above.

For our team, it’s important to have a walk-through that applies to different situations and a doable, generically valid approach. However, after some initial work, the context will dictate the need for different actions.

The solution described below applies to any large, disorganized instance of Jira with obsolete data, and it’s a proven way to diagnose:

  •    What’s going on in the system?
  •    What needs improvement?
  •    What can be standardized?
  •    Who are the stakeholders, and what are their motivations?

A Jira audit in three steps: automation, a project template, and good old human feedback

In a normal audit, consultants manually go into every project to pull information about the schemes being used, write their own scripts and queries, or directly call the Jira Database to perform data analysis there. It’s a lot of work, and it can take days. It’s also expensive and slow for the customer.

1. Automating the baseline diagnosis

Thanks to Projectrak for Jira, our consultants can create a baseline diagnosis of the instance in about thirty minutes:

  •   We create a project script field for each scheme we want to measure.

For example, here’s the script that reads the issue type scheme being used in a project:

 

Here are all of the scripts for you to use:

Copy and paste the scripts to read which schemes are being used in each of your projects from this link

  •    Then we go into the Project Navigator and add the column to check that it’s giving results.


  •    Third, we create a one-field statistical gadget for each script in a new Jira dashboard.

Step 1: Add gadget > One field statistics

 

Step 2: Configure the gadget. Don’t base it on any filter, and choose the pie chart.

 

Step 3: Accept and repeat for each script.

 

Here’s the result:



How to use the statistics: There’s no rule of thumb for what an organized instance looks like by just looking at the workflows. You need to connect to the actual goals of the teams that are using Jira, the organizational chart, and then make conclusions.

In other words, you need to compile context and qualitative data. The remaining two steps are designed to do precisely that.

2. Create a project template to collect information

The project template that we use is a Projectrak layout. This means that it is structured metadata that lives inside Jira and can be associated with Jira projects. For the audits, we associate it with every project and then work on collecting the info.

 

The layout has three sections:

  •    The project sheet, which includes all the feedback from the project leads
  •    Project activity, with automated info about the last activity date and the total issues. This info can be extended as needed
  •    Schemes where the schemes associated with the project are listed

The project sheet is the only section where information must be entered manually. It works like a script for conducting interviews with project leads, like the ones Rachel Wright suggests in this article.

3. Do the interviews

You have to ensure you understand the full complexity with all its angles.

Interviewing each project lead is mandatory for having a full picture and capturing particular details: there might be projects that looked inactive but have simply very little activity; there may be important reasons why their schemes are significantly different from those usually mandated. In general, it’s just common sense that, before deciding to alter a project (archive it, simplify its settings, etc.), it’s important to know the project's intended use in the first place and whether it still captures value.

While interviews can be time-intensive, if there’s enough discipline in the organization, you can also share the project landing in Projectrak and permit project leads to edit the fields.

Tip on notifications: If you’re having trouble collecting information on a handful of projects, you can watch them receive notifications when they’ve been compiled or subscribe to the entire project portfolio to receive regular summaries of the pending information.

 

What next? Choose the best way to control Jira projects

Once all the information has been retrieved and analyzed, it’s time to decide on the project governance model. And if this article isn't good enough, you can always watch the following video explaining this helpful use case:

 

Conclusion: an easy start for something big

The road toward standardization of Jira dinosaurs can be long and exhausting. There’s no need to suffer from manual processes that can be replaced with automation.

This is a summary of the benefits of deploying Projectrak for audits:

  •    A big picture about the customer that you’ve never seen before
  •    Less expensive for the customer: they won’t pay consultant time devoted to manual, repetitive work
  •    Quicker delivery of results and more energy devoted to the interesting part: making recommendations and creating a roadmap towards standardization and defragmentation
  •    Information about the projects is in real-time because it lives inside Jira. As the instance is less fragmented, the visual charts will reflect that

If you are interested in making the tool work for you, you need to be aware of a wide range of automation that might help you maintain audited yous instances; we offer seven use cases when automating projects with Projectrak and Automation for Jira will boost your productivity to the top.

This blog post is a collaboration between the DEISER marketing team and Jaime Capitel.