Jira audits for Enterprises: The best way to automate and diagnose

Jaime González-Capitel
26-sep-2019 17:36:06

Old enterprise instances of Jira that haven't had clear administration policies since day one must be audited. 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.

How many customers of Atlassian started using Jira over 10 years ago? While it’s hard to give an accurate number given the fact 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 their product teams will be using Jira to some extent --almost as much as you can see accountants running their balance sheets on Microsoft’s Excel.

Dilbert about automated and diganose Jira audits

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

A common problem for any old instance of Jira is that unless there are clear administration policies from day 1, time brings chaos and disarray. 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.

We said Jira has become a de facto standard. Becoming an industry standard also means that more and more people are aware of the typical problems a user is likely to encounter… and, of course, these people need quality troubleshooting when s*** hits the fan.

We’ve identified one of those typical problems in 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 with an audit.

Performance is Jira's blue screen...

Audit of several Jira instances.

Use this chart to benchmark your instance's response time against Atlassian standards. From Atlassian's documentation on Performance and scale testing

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. And 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 thousands.)
  •    A large volume of projects with no clear governance (i.e., when and how they should be archived.)
  •    A bottom-up, de-centralized adoption of the tool.

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

  •    Different instances of Jira running on different versions.
  •    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 humungous instance migrating from Server to Data Center, sometimes it’s 22 instances of Jira that have to 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 in that time we’ve encountered most of the situations above.

For our team it’s important to have a walk through that applies to different situations, a doable approach that is generically valid, although 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?

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

In a normal audit, consultants have to manually go into every project to pull the information about the schemes that are being used, write their own scripts and queries, or directly call the Jira Database to make 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 Profields for Jira, our consultants can create a baseline diagnosis of the instance in about thirty minutes:

  •   To start, we create a project script field for each of the schemes we want to measure.

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

Script console of Profields to automate audit enterprise jira instances


And 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
Profields's Project Navigator to make easy Jira enterprise audits

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

Step 1: Add gadget > One field statistics
auditing and standardizing jira enterprise instances


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

How to configure gadgets in Profields for Jira enterprise instances audits
Step 3: Accept, and repeat for each script


Here’s the result:

Automated standard schemes in Profields for Jira

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 Profields layout. This means that is structured metadata that lives inside Jira and can be associated with any Jira projects. For the audits, we associate it to every project, then work on collecting the info.



The layout has three sections:

  •    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 to the project are listed

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

3. Make the interviews

You have to make sure that 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 to what is usually mandated. In general, it’s just common sense that, before making any decision to alter a project (archive it, simplify its settings, etc.) it’s important to know what was the intended use of the project in the first place and whether it stills captures value.

While interviews can be a time-intensive process, if there’s enough discipline in the organization you can also use share the project landing in Profields and give project leads permission to edit the fields.

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



What next? Decide a project governance model

Once all the information has been retrieved and analyzed, it’s time to make decisions about the project governance model.

Conclusion: an easy start for something big

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

This is a summary of the benefits of deploying Profields 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’re interested in using this approach, download the full use case below and share it with your team!

Auditing and standardizing large Jira instances

Start your own audit


If you're interested in using this approach, download the full use case and share it with your team to pave the road to a standardized and highly performing instance!


You May Also Like

These Stories on Jira Software

No Comments Yet

Let us know what you think

Subscribe by Email