Jira Cleanup: How to audit your Jira Instances?

Atlassian team

Cleaning your workspace is a smart first step towards increasing productivity. 

This statement has nothing to do with Marie Kondo’s “The Life‑Changing Magic of Tidying Up”, yet the best practice for every Jira Admin is to review their Jira institution once in a while, document the components that are not in use, and revise the architecture to ensure it is still effective and progressing. Below, we have compiled some of the important steps you need to take in order to get your Jira cleanup started.

Cleaning up your space is not a one-time activity. It typically turns into an iterative process with a basic cleanup done quarterly, and an advanced cleanup – annually.

Basic Cleanup is aimed at deleting redundant entities, increasing server performance, and simplifying the ongoing work process. The first step of  Basic Cleanup is evaluating your current Jira state to assess the mess. Here, you have to prioritize each step of the cleaning process. As an example, take a look at our brief prioritization guide for clients who come for assessment consulting: 

• Organizational Structure;
• User / Group Management;
• License Cost Optimization;
• Jira, Confluence and Service Management Configuration Review.

Let’s review each step in detail.

Organizational Structure

The key areas we look at here are the domain access and the automated rules for accessing the products.

Reducing the number of Jira admins is the first and essential step. As a rule of thumb – the lower the number of admins the better. It is applicable to Server, DataCenter, and Cloud. Ideally, stick to less than four admins per instance.

From a real case: 

Experience shows that most Jira customers start using this tool without deep administration knowledge. Taken from one of our clients’ recent cases, let us share the most common pain points you can face. 

As soon as we got access to the client’s environment, the first thing that struck us was the amount of admins with full administrative privileges – 13 out of 57 Jira users in total. This was explained by the lack of Jira configuration knowledge of the appointed Jira admin. Thus, once a person asked to administer a project, he was given admin rights for the whole Jira instance. 

Apart from that, out of 51 agents in the Jira Service Management, there were only 12 agents that actually responded to customer’s requests. That number of seats was obviously licensed and billed. Due to lack of user access configuration understanding, granting all Jira users access to Jira Service Management to simply view the tickets seemed a viable solution, though resulted in overpaying for the general system. 

What we did

We deleted the unnecessary users, which instantly saved 30% of the total infrastructure budget. We redesigned the processes to enable a set of defined users to view both projects and tickets by setting up 1st level support integration and synchronization between Jira and Jira Service Management (formerly Service Desk). Another integration was created for 2nd level access, which allowed transferring tickets on a different layer. This allowed us to reduce the monthly bill by 50 percent before the actual optimization.

User / Group Management

At this stage, take a look at the access: who can see the projects and what levels of access these users have, according to what rules and parameters these accesses should be built. Consider permissions that should be granted at different levels of use as well as at the levels of different products (e.i. Jira, Confluence, or Jira Service Management).

The rights here can also vary: it is essential to configure which of the users can watch, view, edit, or change.

For our clients, at the assessment stage, we draw up and offer the entire list of recommendations for setting up this hierarchy of accesses in the system. Based on the result of the assessment, you get a full report with advice for improvements, which then you are free to choose how to implement: with the help of a solution partner or by yourself. 

From a real case:

Historically, it was easier to define user groups for specific purposes on the client site. The demand for certain users to have certain rights within different projects grew – so grew the number of user groups. Basically, it resulted in 20 user groups for 70 users with quite an overlapping user base and some user groups consisting of one member. 

What we did

We reviewed user groups, revised and eliminated the unnecessary ones. The next step was introducing permission schemes based on user roles, which allowed a far more flexible project access configuration and actions within these projects. 

License Cost Optimization 

At this stage, you can answer the following questions:
What apps are installed?
Which of them are used?
What are you paying for? 

How much?

And you will get the answer to the main one: How to optimize the costs?

Here, it might be a good idea to deactivate your unused licenses of products, add-ons, and third-party tools as well.

From a real case:

The client did not know how to set up access for the development team, for developers to have limited access to projects without providing them with agent licenses. Thereby, they overpaid huge amounts instead of integrating systems with access settings. The decrease in agent licenses resulted in a 67% budget cut.

Another common case we encounter is installing a certain app trial, or even a few apps that serve the same purpose to evaluate them. The key point here is to remember to switch them off, when you no longer need them. Once, while transitioning a client’s setup from monthly subscription to annual, we reviewed all active add-ons and, as a result, switched off 70% of those, as they were not in use, and real business needs were covered with the remaining 30%.

Jira, Confluence, and Service Management Configuration Review

What needs to be done at this stage?

To unify processes, look at the existing system and understand which identical entities can be merged. 

For our clients, we offer recommendations for every product. For example: 

• Jira configuration review. Setting up roles and permissions, reviewing custom fields, archiving unused projects, inactive workflows, deleting issues and screens are the main steps during this stage. 
• Confluence setup overview. We give recommendations which templates will better suit the client’s needs.
• Jira Service Management review. We recommend how to connect it with Jira, how to configure it, and what options for implementation can be foreseen. Besides, the review includes incident management, change management, and setting up any internal processes (e.g. office equipment replacement, new employee adaptation, standard contracts, etc.)

From a real сase:

The client had 243 screens for 250 users within 77 projects. 15 duplicated resolution screens. The projects were primitive, all inherited simplified schemes with separate workflows for each project. The same referred to workflows, which were made unique for each project. Parsing each of these entities resulted in a 43% increase in server performance. 

All these manipulations can be performed without granting a Solution Partner access to actual project data, only to configuration. This way you ensure your customer data privacy  while being accessed by a third party.

It is worth noting that the whole process is “EASY” to set up using Atlassian tools.

We call this type of cleaning  – Advanced Cleanup, which is skillfully and efficiently performed by Сertified Atlassian Professionals. Typically, Advanced Cleanup requires preparation and hard skills in Jira Administrating. With the necessary skills, you can easily deal with it step-by-step.

Don’t want to do it by yourself? As an Atlassian Solution Partner, we provide cleanup for our clients – Assessment Phase.

3 easy steps to make the Atlassian Tools Assessment with Rozdoum:

1. The First 30-Minute Call;
2. Analysis stage;
3. Final Assessment Report.