Best Practices for Jira Software Governance: Projects, Statuses, Custom Fields, and Apps

The first step on the Atlassian governance journey is to establish a governance board, or a community of practice. The board should be comprised of a group of people who reflect the makeup of the entire user base, so that all voices are heard. It’s the role of the governance board to take in requests for changes to the system and processes, weigh the potential benefits of them vs. their impact on the system, and determine if it makes sense to implement them.

The goal of the governance board isn’t to prevent changes in Jira, it’s to support change and evolution of the tools so that they continue to support strategic business objectives, user efficiency, and the overall health of the system. This is no small or easy task—requests for changes will come up often, particularly around projects, statuses, custom fields, and apps—so in this blog post, we have rounded up a few best practices for Jira governance.

Project Governance

A best practice is for shared, company-level projects that roll up to strategic, corporate-level business initiatives to all be consistently structured. They should share common schemes and use consistent nomenclature for statuses. These commonalities ensure visibility into progress and roadblocks that may need to be addressed, especially if there are dependencies, and they make reporting much more efficient.

Many organizations find, however, that it makes sense to deviate from this structure for projects that, for whatever reason, are not shared, company-level projects. We’ve seen use cases around R&D, as well as projects that are designed to allow for experimentation with the tools and processes. It can be quite valuable to identify specific opportunities to test new processes so that users can continue to evolve the way they use the tools.

Status Governance

Too many different statuses create confusion for users and make it challenging, if not impossible, to get a high-level understanding of the status of work in progress. Often, the culprits here are that teams are using different words for the same status, or the same word for two different statuses. A best practice is to establish consistent nomenclature for statuses to be used across all projects.  

Custom Field Governance

Too many custom fields can create confusion for users and negatively impact the performance of a Jira instance. Without proper governance in place to vet new custom fields to determine if they are really necessary before they are added, companies often find that they have duplicate fields, obsolete fields that are no longer used, and fields for edge use cases that seldom get used. A best practice is to establish nomenclature for common field types across the company, and ensure that new custom fields are checked against this list before being added.

App Governance

Too many apps can have a negative impact on system performance, especially if there is a lot of data associated with them. Duplicate apps, different apps that serve similar purposes, or apps that are underutilized, are also an unnecessary expense. When requests for new apps are made, the governance board and/or the admin team should thoughtfully consider the underlying problem the app addresses. Is there another way to solve the problem that will have less of an impact on the system? A best practice is to limit apps to those that serve the broader user base and create significant efficiency. For edge use cases, it may be better to find a workaround.