Is your company’s Jira not fulfilling business needs and resulting in user dissatisfaction? Here are four potential issues and their solutions.

A Jira power user is the application’s administrator with extensive admin rights to configure and manage Jira, who is typically responsible for tasks such as:

• Creating and setting up Jira projects according to best practices;
• Managing system settings like global permissions, mail servers, database monitoring, and more;
• Handling user management;
• Managing applications and integrations;
• Training, assisting end-users, and clarifying their needs.

The value gained from Jira heavily depends on how projects are set up. Following configuration management best practices allows for sustainable planning, measurement, and analysis within projects.

On the other hand, managing system settings, applications, integrations, and users is crucial for both the performance and security of the environment.

A good power user has a deep understanding of the application, technical knowledge, and experience.

We've observed that in rapidly growing organizations, Jira management often becomes a side task performed alongside primary job responsibilities.

This often means that the person with administrator rights lacks sufficient knowledge of best practices for application management or the skills needed to handle configuration elements effectively.

The absence of a dedicated Jira lead administrator often results in configurations being made on the fly to quickly meet all end-user needs and get projects moving.

Although this approach may be effective in the short term, achieving good Jira hygiene and valuable solutions in the long run requires systematic management.

Therefore, a Jira power user plays a crucial role in ensuring that management standards are consistently applied when maintaining the system.

By management standards, we understand defined procedures and best pracitces that the power user follows when managing Jira.

Following best practices helps to:

• Avoid overwhelming administrative workload;
• Create accurate and realistic reports and analytics;
• Ensure the sustainable operation of the system;

While specific management standards may vary between organizations, it’s wise to start with aspects that have a broad impact.

What Types of Projects Are Created in the System?

Atlassian’s Cloud platform offers two different project types: team-managed and company-managed.

Team-managed projects may seem quick and convenient to set up but the configurations are isolated and limited.

Team-managed projects can quickly become a stumbling block when there’s a need to create cross-project reports, views, or analytics.

Can Any Configuration Elements Be Reused?

A new Jira project can be created based on another project’s settings, allowing you to reuse existing configurations in the system.

These are essentially template projects where tickets are not managed; their purpose is to serve as the basis for creating new projects.

Example Scenario: A company that offers software development services distinguishes between large-scale and small-scale development projects. They have decided to implement Jira for project management.

In the example scenario above, a good starting point for Jira implementation would be to map the processes for both large-scale and small-scale developments.

Additionally, a power user needs input on data fields, permissions, and notification requirements.

This overview serves as the basis for configuring template projects, which are then used to create new development projects.

Project templates significantly reduce administrative overload and prevent the creation of redundant, duplicate configuration elements.

What is the Frequency of Jira Cleanups?

Regular cleaning of Jira ensures optimal system hygiene.

It’s advisable to follow the principle that the larger the company and the more Jira projects there are, the more frequently cleanup activities should be performed.

The recommended frequency for Jira clean-ups is at least 1-2 times per year.

What are the Language Guidelines for Naming Configuration Elements?

We’ve seen Jira environments where configuration elements like workflow statuses, custom fields and issue are created in multiple languages.

While it may not always be feasible to use only one language, it is helpful to establish a primary and secondary language. This approach makes working in Jira more intuitive for end users.

Groups or Roles?

Groups and roles are primarily used for configuring permissions, notifications, and issue-level security. Both groups and roles have their advantages, but roles allow for more flexible management.

Jira's configuration elements are essentially the building blocks that form the foundation of a project. These elements are associated with schemes, which are then associated with a project.

As an organization grows, Jira projects are often created in an agile manner with a strong emphasis on quickly meeting end-user needs.

Over time, this can lead to the accumulation of numerous configuration elements that may not actually be used or that essentially duplicate one another.

Common examples of such duplicate elements include custom fields, workflow statuses, and issue types.

Jira’s backend doesn't have a restriction that prevents administrators from creating configuration elements with the same name.

As a result, it's not uncommon to encounter multiple custom fields that share the same name or have slight variations but convey the same concept.

While duplicate configuration elements might not immediately impact system performance, they can quickly lead to confusion and frustration for end users.

Example Scenario: User wants to create a query to find all tickets in Project A where the field "Country" has the value "Estonia."

When using the JQL (Jira Query Language) module, a custom field ID code is displayed next to the field name. However, this metadata is typically not something that end-users know or should need to know.

Fields with identical names end up cluttering the system and hamper an efficient and user-friendly Jira experience. But why do multiple fields with the same name appear in the system?

Often, multiple fields with the same name (such as a multi-select field) are created when there’s a need to use the field across different projects but with different options specific to each project.

Instead of creating duplicates, we recommend addressing this requirement by adjusting the configuration of the custom field.

Example Scenario: A user wants to find all issues in Projects A, B, and C that are currently under analysis. Projects A and B share the same workflow, while Project C follows a different workflow.

The end-user might not notice that the workflows of the three projects differ when it comes to statuses like “Analysis” and “In analysis".

Without noticing this difference, the end user may create a query such as project in (A, B, C) and status = "In analysis", which means that issues in Project C in status “Analysis” will be excluded from the query results.

Over time, a significant number of projects and tickets can accumulate in Jira, many of which may no longer be in use.

From a business requirements perspective, it’s understandable that projects and issues must not be deleted, but leaving them in Jira clogs the system and slows down issue search.

When a project is archived, along with its tickets, they are removed from the Jira index so they no longer appear in the search engine, boards, or dashboards etc.

Archiving completed projects helps maintain a clutter-free environment and ensures faster search query results. It should be an integral part of regular Jira maintenance.