JIRA Administration - Best Practices

In recent years, Jira has become the leading bug tracking, issue tracking, and project management tool, and is used by majority of Fortune 100 companies. The software offers a variety of innovative and flexible features, which allow users to get the best out of the platform. With years of experience working with large/medium organisations on Atlassian products as end-user, subject-matter-expert and administering instances, there are many areas that have I have learned the hard way. Especially, as an Jira administrator, the hardest part being where you need to strike balance between IT and Business by ensuring you provide what the end-users need as part of their customization project to support their business process, and at same time keeping the instance performance at an optimal level by avoiding too many custom fields, schemes, configurations etc. 

You will find various tips, tricks, best-practices shared by the community and users across the industry. Some of these may seem obvious in theory. However through experience we know that sometimes you need to go back to basics, especially when it comes to supporting company infrastructure. In a typical case of a Jira instance that has evolved and grown in line with changing needs - its configuration must have become complicated, its performances may be falling short of the mark, and to top it all, no one really knows how to best administer it. To reconfigure it – and ensure it will function well in the future – a good dose of best practices is needed for its implementation. 

(Note: We read various best practices, tips & tricks spread out there on internet through various blog posts, articles, Atlassian User Community posts, Atlassian's product documentation, Atlassian Solution Partners etc. This article is an effort to share my own experience and best practices coupled with best practices implemented by Jira experts across the industry.)

Here it goes.... 

Administration & User Management

1. Limit the number of administrators. Having a core group of admins that know every moving bits of Jira and its effect ensures each change is made with consideration.
2. In global organisations, "follow-the-sun" support model is setup where key system administrators are located in different time-zones to provide round-the-clock service.
3. The Jira Administrator must be go-to person to drive training, best practices, usability, and overall efficiency. An administrator without the necessary skills/experience may have a negative impact on all users, if they don't know how to manage issue types, workflows, schemes, custom fields, and most of all promote re-usability.  
4. Establish on-boarding documentation for new users to start on the right foot, know the intention of Jira, and exactly how to use it. 
5. Promote "project roles" preferably over "groups", as Roles helps to make schemes more generic, easy to maintain membership, and can be managed by project administrators thereby taking the load off Jira Administrators. (Read more about Managing project roles)
6. Keep Jira upgraded to latest versions where Project Level Administration features are extended & puts some of the admin power into project administrator’s hands without giving them the keys to the kingdom.
7. If you are on Data Center version, architect the infrastructure to route REST API traffic to specific node(s). This will allow to alleviate the load at its application nodes.

Schemes, Templates & Configurations

1. Do not modify the defaults configurations. For example if you have custom fields or custom issue types - add them to custom field type schemes and custom issue type schemes. 
2. Establish naming conventions. When working with different teams with each having unique needs, make sure you follow a consistent naming standards for schemes and templates. For ex: Marketing Screen Scheme rather than just Marketing.
3. Use "create with shared configuration" wherever possible and after due-diligence. 
4. Create at-least 2 or 3 organization templates for "field-configuration", "screens schemes", "workflow", "issue-type schemes", "notification", "permission" that captures majority of your organizations/project needs. Whenever, a new project is requested, the Jira Administrator can associate these template as starting point for the teams to on-board.
5. Decide the organisation policy on the type of attachments you will allow within Jira issues. I have personally seen companies allow only images to ensure users do not attach all sorts of documents to the issues and make Jira an file-store. 

Custom Fields

1. As an organization grows and adopts Jira for varied purposes, the number of custom fields grows along with it. The underlying problem with custom fields is that the Lucene index.
2. Don't create custom fields with duplicate names; reuse existing fields where possible. Make use of field contexts.
3. Ensure that field serves a justifiable purpose and can be consumed across majority projects rather being more project specific. Know how and when to use custom field contexts
4. Give your custom fields useful descriptions, including examples of valid field values
5. Be careful of trailing spaces or other non-visible characters added to the custom field names.
6. Conduct quarterly audit to see how custom fields are actually being used on quarterly basis.
7.  Find out everything you can about each add-on or admin created custom field. Look for clues in the Jira’s application audit log; the add-on audit log; or check the plugin’s documentation.

Add-Ons

1. The most common mistake on Jira instances is the use of random add-ons. Some have little impact on Jira, while others will really alter your Jira instance. The Jira administrators should vet the add-ons by asking following questions.

• Is this add-on available on Atlassian Marketplace, Atlassian Verified & Data Center Supported (if your instance is Data Center version)? One of the client that I was working with, the company had a policy to evaluate/procure add-ons from vendors that uphold Atlassian standards for app traction, timely support, and vendor reliability. Read more about Top Vendor program)
• Does the add-on has enough positive reviews by the community?
• Are there any functional, technical or performance related known bugs, issues reported by the community?
• Does the add-on have a good release rhythm & relevant documentations, user-manuals?
• Does editor of this add-on have good technical support model/team to assist the users?
• Does the editor release a compatible version of the add-on within a month after a major Jira release?
• Does this add-on answer only my project need OR can also be used in other projects, business units?
• Is the price justified vis-à-vis the features & benefits provided by the plugin?

Jira Change Control Board

1. The primary role of the CCB will be to : 

• Decide what customization to create and support in order to strike a balance between giving teams what they need and maintaining a manageable, high-performing application.
• Set standards for privacy, security, and storage and handling sensitive information.
• Develop a process for providing support for teams’ Jira projects.

Setup a Jira Change Control Board using Jira Support project (or Jira Service Desk) which can be used for just this purpose. Your Jira Support Project is the mechanism for

• Creating and archiving Jira projects
• Managing customizations and requests for customizations
• Responding to user support requests
• Measuring how well the support team is performing

Have a team of Jira SMEs who serve as liaisons between Administrators and the Jira users. SMEs are important allies in answering common questions or getting the word out when there’s a change to your application or your procedures.

Have an sand-box environment where proposed changes could be implemented, experimented with, demoed, and trained. Additionally, having an pre-prod / UAT (production like environment) will help to deploy the customization project on UAT instance for business users sign-off, executing performance tests etc. 

Follow the best practices for promoting Jira configuration from the development to production environment using 3-tier architecture strategy from Atlassian. Use Configuration Manager (or similar) add-on to effectively to deploy changes in the production environment.

Others

1. Archiving - As the number of issues in your instance grows, so does the index. This can create clutter for your team if they aren’t narrowing down their searches enough. Consider whether or not a retention policy needs to be implemented and whether or not archiving is an option for your instance. Removing no-longer-needed issues keeps Jira tidy and easily searchable, and can help to avoid performance problems related to the sheer volume of issues accumulated
2. User Re-certification - If you are limited on Jira user licenses, you can implement user re-certification process, whereby users who haven't logged-in for a certain period of time (say, 60 days) will be informed by email and given a grace period to log in. After the deadline, user still inactive will be revoked from Jira (i.e. marked in-active). This will ensure users do not just un-necessarily consume the license and the same can be allocated to development team/users.
3. Project Re-certification - Every Jira instance will have projects which are created but haven't used since long time. These could be created for demo, proof-of-concept, learning, training etc. To keep the instance tidy, similar to user re-certification, the Jira administrators can implement project re-certification. This process will check for projects which are created (say 90 days before) and (a) do not a single issue created, or (b) not a single issue being updated. The Jira admins can reach out the relevant project lead in automated way via email and seek for deleting/archiving of the project. One of my client had DC instance hosted with 6K+ projects and with this re-certification process almost 1500 projects unused.
4. Subscribe to Atlassian newsletters and blogs, follow Twitter accounts Atlassian-related, Linkedin forums and people that are working with Atlassian products, "watch" confluence spaces of official documentation, etc.

As with everything, the best way to learn is by doing. The best way to get to know Jira is to put yourself in contact with people who have a lot of Jira experience. They’ve learned some lessons the hard way and are very generous about sharing their expertise. Here are a few recommendations:

• Atlassian Community Forum - The Atlassian Community is a great place to get advice and pose questions. 
• Atlassian User Groups - Atlassian User Groups (AUGs) are a good place to network with other users. 
• Atlassian Solution Partners - Atlassian Solution Partners are consultants who specialize in helping you implement solutions using the Atlassian toolset and can help you define your scope as you get started or clean up a Jira instance that’s gotten out of hand. 

So, all Jira Administrators out there.. Do you have any other tips, tricks and best practices to share? Let them come out..