Jira anti-patterns to avoid as your system scales

Jira anti-patterns to avoid as your system scales

This blog post will explore some of the many default Jira anti-patterns identified by Atlas Authority.

Jira software slider logo

Pop-ups such as “project tips for getting started” are intended to help users familiarise themselves with Jira projects and enable the use of more Jira functionalities. However, as systems scale they can become more of a nuisance than anything else.

Default settings may appear useful at the beginning of your Jira journey, but the problem is, they don’t scale as the organisation and usage of the tool expands. As such, companies often call in experts to undo these practices, which can be very time-consuming.

Define the process first, and create a flexible workflow where issues can transition to most statuses.

Whenever you create a classic software or kanban project, it will default to this Workflow automatically, unless a shared configuration is formed. Instinctively, users generate issues upon creation of a new project, and while there’s nothing wrong with this, doesn’t it make more sense to have the process defined beforehand?


By default, Jira will not ask you to choose a workflow when starting a project. It’ll ask for other information such as project name, type and key. This doesn’t sound like an anti-pattern? It does when you end up with an unmanageable system because the project was not initially defined, resulting in the creation of new workflow schemes, the migration of issues within current projects, and training for users on how the new process works.

Schemes

During the Atlassian journey, there are a few schemes worth paying attention to, these include Workflow, Issue Type, and Screen Schemes.

Why are these important? Because they help users apply quick configurations to projects, although if not properly configured, can impede progress in Jira.

If new projects are not created with “shared configurations”, Jira automatically creates new schemes (Permission, Workflow, Issue Type, and Screen). This results in clutter within the admin panel, thus slowing down your instance, regardless whether you use 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. Therefore, once you open your new Jira instance and start creating projects, you’ll actually end up hurting your chances for success by cluttering your instance with unnecessary schemes. And while this may not seem like a big deal to less experienced administrators who’re new to Jira, when it comes to long-term planning, go for shared schemes.

Reindexing

As a server administrator, whenever changes are made to Jira configurations, i.e. adding in a Custom Field, a pop-up box will appear, prompting you to perform a re-index almost every time.

If you’ve ever wondered whether you should reindex every time, the short answer is no, especially if you have active users.

Background reindexing can take a long time, resulting in performance issues within your instance, and a foreground re-index makes your system completely unavailable!

In saying this, there are certain things that 100% require reindexing, i.e. following an upgrade or if you changed the Searcher for a field, which could cause the index to break, resulting in incorrect search results.

Custom field contexts

When a new Custom Field in Jira is created, it uses a default context that applies to all issues in the system. What this means is, Custom Field Context allows you to choose which Projects or Issue Types the Custom Field appears in and customises 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, 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 decreases the performance of your instance. Different Custom Field Contexts, ease administration of Custom Fields, improve the Jira UX for searching, and improve end-user UX with cross-project behavior of fields.

Knowing when to break the Jira anti-pattern

Overall, I think it’s fair to say, Jira is a very user-friendly tool, especially to those new to the software.

However, to ensure your growing business scales accordingly, there are some default settings you need to be aware of.

If you’ve identified with any of the points listed in this post, you’ll be glad to know we provide training in Jira, as well as other Atlassian products. We can help evaluate an existing instance to maximise its capabilities, or if you’re new to Jira, we can help with the set-up, saving you time and money by defining the process before work even starts.

 

Get in touch with us today to enquire about any of the above.

 

Share on facebook
Share
Share on twitter
Share
Share on linkedin
Share

Reader Interactions