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.
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.
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:
Here are some signs of a corporate Jira crying for an audit:
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.
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:
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.
Thanks to Profields for Jira, our consultants can create a baseline diagnosis of the instance in about thirty minutes:
For example, here’s the script that reads the issue type scheme being used in a project:
And here are all of the scripts for you to use:
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.
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:
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.
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.
Once all the information has been retrieved and analyzed, it’s time to make decisions about the project governance model.
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:
If you’re interested in using this approach, download the full use case below and share it with your team!
Copyright © 2020 DEISER
Copyright © 2019 DEISER
Copyright © 2019 DEISER