Jira Anti-Patterns to Avoid in a Growing Organization

There are many ways Jira helps users adapt and get started when initially using the tool. The “project tips for getting started” pop-up that appears after you create a project is a great example of Atlassian’s attempt to onboard new users.
These tips are intended to help you familiarize yourself with a Jira project and further enable you to use more Jira functionalities. While Jira is full of these helpful features, they become less helpful (and effective) as the system scales.

Atlassian has done their best to give new users and admins the best chance to succeed, but not everything is perfect. From our experience consulting with teams using Atlassian tools (across various industries and organization sizes), we have come to recognize many of the default Jira anti-patterns. These default settings might appear useful at the beginning of your Jira journey, but don’t scale as the organization and usage of Jira grows. We spend a lot of our time undoing these practices. Here are a few Jira anti-patterns you should avoid to protect and support your organization as your Jira system grows.

Jira Anti-Pattern 1: Workflow

Let’s start by saying, we think the Default Jira Workflow is great for some teams. It looks like this:

While this is a great Workflow for novice administrators getting started, it might not scale well or be useful for your organization.

Whenever you create a classic software or kanban project, it will automatically default to this Workflow (unless you create as a shared configuration). Users instinctively create issues once they create a new project. And rightfully so! This is the purpose of Jira, right? Imagine having a task management tool with no tasks. On one hand, creating issues and populating the tool makes sense. On the other hand, shouldn’t you have your process defined before you start your work?

By default, Jira does not ask the user to choose a workflow when they create a project. They ask for other information such as project name and project key. They also ask you to choose the project type.

So, why is this an anti-pattern? Often times we find that users begin working with Jira without defining their process and their system becomes unmanageable. Companies of all sizes then contact Atlas Authority to help them define their process and workflow. This results in the creation of new workflow schemes, migration of issues in the current projects, and training for users to show them how the new process works. As much as we enjoy working with our clients, we want to inform others how to properly get started with Jira.

At Atlas Authority, we suggest getting buy-in and defining the workflow before work actually begins. We normally advocate for a more flexible workflow where issues can transition to most statuses. Here is an example of a Simplified Workflow:

This is an example of a good generic out-of-the-box Workflow that you can use in Jira. We recognize that it will not work for every organization, and some organizations will need individualized Workflows, but we have pleasantly surprised a number of teams that gave very open workflows a try. Of course, if you need help customizing your workflow please don’t hesitate to contact us.

Jira Anti-Pattern 2: Schemes

We talked extensively about The Perfect Permission Scheme in our previous blog. There are a few other schemes that you need to pay attention to during your Atlassian journey. These include Workflow, Issue Type, and Screen Schemes. These are important because they help you apply quick configurations to projects. Unfortunately, if it is not configured correctly, they can also impede your progress in Jira.

If you don’t create your new projects with “shared configurations” Jira will automatically create new schemes (Permission, Workflow, Issue Type, and Screen). This will create clutter within your admin panel and could slow your instance down, regardless if you are on Jira Server or Cloud.

This is an anti-pattern because, by default, Jira will not select the option of “create project with shared configurations” for you. So once you open your new Jira instance and start creating projects, you’ll actually be hurting your chances for success by cluttering your instance with unnecessary schemes. This might be fine for organizations who are new to Jira and have inexperienced administrators, but when it comes to long term planning, shared schemes is a better option.

Jira Anti-Pattern 3: Reindexing is Required

As a server administrator, whenever you make changes to most Jira configurations, like adding a Custom Field, Jira prompts you to re-index. A box will come up that says:

Should you reindex every time? The answer is no. Many of our consultants have administered instances where they didn’t reindex for many months. Jira will prompt you to reindex nearly every time you make a configuration change. You don’t need to do it, especially if users are active. Background reindexing can take a long time and can cause performance issues in your instance. A foreground re-index makes your system completely unavailable.

However, there are certain things that should definitely be reindexed, but many of them are not required. For example, one reason to re-index would be if you changed the Searcher for a field. This could cause the index to break and result in incorrect search results for a user. Another example of a good time to reindex is after an upgrade.

With that being said, it is good to reindex every so often or if users start complaining about inaccurate search results.

Jira Anti-Pattern 4: Custom Field Contexts

When you create a new Custom Field in Jira, it uses a default context that applies to all issues in the system. What does this mean and what are the implications? Custom Field Context allows you to choose which Projects or Issue Types the Custom Field appears in and customizes the configuration of those Custom Fields within the Projects or Issue Types. As an example, it’s possible to have different default values for the same Custom Field in different projects.

By default, all new Custom Fields are enabled in a global Custom Field Context which is applied to all Projects and Issue Types. Having all custom fields applied to all Projects and Issue Types is an anti-pattern because as your instance grows, having all fields applied to a global context will decrease the performance of your instance. Moreover, having different Custom Field Contexts will ease administration of Custom Fields, improve the Jira UX for searching, and improve end-user UX with cross-project behavior of fields.

Jira Anti-Pattern 5: Terminology

Not necessarily an anti-pattern, but we found there are a few pieces of key terminology within Jira that are confusing for new users.

Versions and Releases

The first two are versions and releases. Versions indicate actual versions of your software. A release could merely be a date. It is more like a time-box where multiple versions could be contained. Depending on how your Jira is configured, these fields could be the same. And depending on the version you are on, you may end up with parts of the UI saying both in different places. For most people, they should be considered as the same thing.

Edit and Configure

In the administration panel, there are two other words that are similar but have different definitions – edit and configure. For example, looking at a custom field menu, what is the difference between edit and configure?

If you “edit” a custom field, you are changing the Description, Field Name, or Search Template. If you “configure” a field, you can change the field configuration scheme or default value for that custom field. A good rule of thumb to remember is, for the “edit” option, you can rename or describe the Field or Screen, but with “configure” you can change the options, context, or default values. However, this is different with Workflows. If you choose to edit a Workflow, you can actually add/edit/delete transitions and statuses.

Epic Status and Workflow Status

The last pair of confusing terms are Epic Status and Workflow Status. Workflow Status is the state that your issue is in. In the Default Jira Workflow, the state could be Open, Closed, In Progress, Resolved, and Reopened. Since an issue can be an Epic, it could have any of these statuses. The Epic Status is the status of all the issues that are contained in the Epic, aggregated and falls into three options: To Do, In Progress, and Done. If you want to link these up check out this article in Atlassian’s documentation.

Breaking the Jira Anti-Pattern

All in all, Jira is a very friendly tool for new users. However, as an organization matures, there are some default settings that users need to be aware of to ensure the system scales properly. Contact Atlas Authority if you need help setting up Jira, or would like to evaluate an existing instance to maximize Jira’s capabilities for your growing organization.