How to Manage Jira at Scale

The Beat of a Single Drummer

One of the most amazing features of Jira has always been the loose coupling of Issue Types, Custom Fields, Screens, Workflows, and the other core components that make Jira so flexible. Atlassian has done a great job of creating a tool that allows you to create Projects the way you want to.

Unfortunately, an asset can easily turn into a liability. Without careful guidance, all of the options available in Jira can quickly lead to an environment rife with Projects that have no consistency. While it is true that different teams will work in different ways, a lack of Project standards is not good for an organization. It leads to difficulty in inter-team communications, reporting, and resource shifting. Additionally, large numbers of unneeded objects–such as Custom Fields–will be created, degrading performance, increasing the burden on administrators, and making migrations and upgrades much more complex.

The best mitigation strategy for these issues is the use of template Projects. Template Projects leverage the power of Jira Schemes to codify your organizational processes. There is upfront time for these template Projects, where you will need to determine what Issue Types, Fields, and Workflows are core to your business. Don’t try to distill everything into one or two Project types. Different organizational units will have different ways of doing things with different needs, requiring multiple template Projects. Try to minimize replication, especially where Custom Fields are concerned. However, don’t be afraid to differentiate your objects. When you instantiate new Projects using these template Projects, in most cases you will want to choose the shared Schemes option when creating new Projects. This can be a double-edged sword. While it will make it easier to create and modify Project structures… it will make it easier to create and modify Project structures. Your users will invariably ask for changes to their Project. Maybe they need a Custom Field required or a new step in their Workflow. This can lead to either:

(1) having to create a new set of Schemes for a single Project or

(2) polling Project teams using the shared Schemes for impacts the change will have on their Project.

One area that is often neglected when creating template Projects is documentation. Adding documentation to your knowledge base describing the purpose of a specific template Project, the Workflows it uses, as well as the Issue Types and Custom Fields it brings, should be an essential part of template Project delivery. This will help users choose the proper Project types when requesting a new Project, add in user training, and generally cut down on questions to your Jira administrators about the Projects.

Room To Grow

Out of the box, Jira’s rich feature set and configurability give it the ability to meet a wide range of organizational needs. However, the time always comes when you will need more functionality. Fortunately, Atlassian has supplied a rich set of APIs to expand Jira, which exposes greatly enhanced functionality. As a result, Atlassian has an extensive ecosystem of third-party Apps for all of their tools. It is important to follow a deliberate process when installing new Apps in Jira. There is both a cost and performance impact to adding new Apps.

General App Considerations

Cost is the first consideration many organizations take into account when purchasing new Apps. These can vary widely based on exposed functionality and vendor. Pricing is based on the total number of Jira users, not just the users who will be using the App. For example, if an HR department needs an App that will only be used by five people but the Jira instance has 1000 licensed users, the pricing will be based on the 1000 user number, not the five.

A second consideration to make when purchasing Apps is the overall effect on system performance. Every App you add to Jira uses the same system resources as the base Jira installation. This means that every App, to one degree or another, impacts overall system performance. Over time, you may experience degraded performance, whether from the impact of a few resource-intensive Apps or the thousand cuts of an overabundance of smaller Apps. When looking into performance issues in a Jira instance, Apps should always be one of the first parts of the environment that is scrutinized.

An often overlooked but vitally important consideration when purchasing Apps is the need for Jira administration. While many of the features found in Apps may be exposed to Project administrators and normal Jira users, most Apps require Jira administrator privileges to configure. Every new App that is installed has the potential to drain away time from your Jira administrator team over the course of the App’s existence in your ecosystem.

Business Case for an App

To ensure a positive App experience, the first thing you should do is wrap a good governance process around Jira Apps. Requesting new Apps should be part of an overall Jira Project set up to help with the administration of Jira. It could even be argued that administering Jira Apps should have its own governance Project. Anyone making a request for a new Jira App should provide a business case for the App.

There are several questions the requestor needs to address:

• Why is the App needed by their business?
• Can the App be used by the greater business?
• Where is the budget for the App coming from?
• Who will be the owner of the App?

The first question is often the easiest to answer, since they wouldn’t have proposed the App without a need within their business. The second question may be more difficult for the requestor to answer because they may not know how other parts of the business function or what their needs are. This may require legwork on their part, but is essential due to the cost of the App being based on the total Jira user count. This leads directly into the question of budget.

Will the business unit be responsible for the cost of the App for the first licensing year? For the entire lifecycle of the App in your environment? Is there a general bucket for App costs across the organization? The model varies across organizations and there isn’t a single standard.

While having a business unit pay for the App will make them consider more carefully what they are requesting, it may prevent them from asking for vital features they need in Jira. This can lead to lack of adoption of Jira and potential fragmentation of information across disparate tools.

Finally, establishing the owner of an App is probably the most overlooked question when adding new Apps. While the easy answer is to say that the Jira administrators are the owners of all Apps, this is seldom correct. True, Jira administrators will be responsible for administering an App. They are not the experts, however, on whether an App is still in use and how it is being used. The owner of an App should be a point of contact for Jira administrators when they have questions on current business usage of an App. Owner information should be maintained, transitioning to a new owner when the current owner leaves the team or organization.

Managing Instances With Intent

It’s All About the Spin - Environment

Once you’ve figured out your initial node architecture, you will need to start planning how you are going to spin up your servers. There is no one single standard on how to architect your environment—it will vary from organization to organization. Maybe you are forced to run bare metal servers, or maybe you are fully ensconced in AWS or GCP. You may run Windows or Linux. Your organization might already be heavily invested in orchestration software or new to tools like Ansible.

Whatever the case, there are questions and considerations that should be taken into account before actually spinning up servers.

First, since you are operating at scale, you will need dedicated environments. At a minimum, you should have development, stage, and production environments. While it is okay to have your development tier differ from your production tier, you should try and mimic production as closely as possible. Stage, on the other hand, should be as close as possible to your production environment. Remember, stage environments are your final sanity check before production.

These are the minimum considerations for your Atlassian environments. It is often a good idea to have the ability to instantiate multiple development environments in an ad hoc manner. One environment could be dedicated as a sandbox for your users to test out changes to Workflows, Schemes, Custom Fields, and other features that they are not able to directly modify in production due to permission restrictions. A second development environment could be dedicated to testing out API calls, third-party integrations, and Apps. A final development environment could be reserved for testing out newer versions of Jira as dictated by your organization’s change management processes. You may also need to create instances for specific business units to test.

Regardless of how many environments you choose to have, you should configure your orchestration with enough flexibility to add new environments in the future. One of the biggest problems organizations get into is using orchestration that is so static that they can’t accommodate changes without substantial rework, costing significant time and resources.

Additionally, you’ll want to ensure that your orchestration process is well documented. This sounds like common sense, but documentation is often neglected. Far too frequently, the information required to properly create environments is partially documented and partially retained in the head of an IT resource. From an organizational standpoint, this is a significant risk.

When working through creating environments, you will also need to consider how those environments are populated with data. The standard approach is to populate lower environments with copies of production data. This is the simplest case, but also one with a hidden danger. Often, development environments have looser restrictions on admin privileges, which allow users to experiment with Workflows, Schemes, and Custom Fields before requesting production changes. Unfortunately, this can easily lead to a scenario where users are able to access data they normally wouldn’t be allowed to see, such as HR tickets. When copying data between environments, you must be very careful with permissions and should consider scrubbing data, such as not copying sensitive Projects into certain environments.

Another common strategy for new environments is to only pull over a subset of Projects. There are several Apps in the Atlassian Marketplace that make this process easier. As an added bonus, these same Apps will help you promote Projects and Jira artifacts between environments. This is very useful when teams are testing out Workflows, Schemes, and Custom Fields in development environments. If you use one of these Apps, you will need to wrap a change management process around promotion, leveraging your stage environment.

User Definition and Roles

Know Your Role

Knowing the difference between Jira user groups and Project roles is essential to scaling your instance. While the distinction is a simple one, many people get them confused. At their simplest, Jira user groups are global, cross-cut groupings of users. If a user is in a Jira user group, they are in that group for every Project. Project roles, on the other hand, are more granular, allowing you to provision users at the individual Project level. Just because a user is in MY-PROJECT-ROLE in one Project does not mean they have that role in another Project.

You should make sparing use of Jira groups. In a scaled environment, these should be controlled in your directory solution (e.g. LDAP, Active Directory, etc.). Of course, this also means that the team managing your directory has additional administrative overhead, both during onboarding and offboarding users.

Additionally, if users need to be added to/removed from groups during the course of their association with your organization, your directory managers will need to be involved.

Project Roles, on the other hand, are managed by individual Project administrators. If a Jira user needs to be added to or removed from a role for a Project, it is a simple matter for the Project administrator to make the appropriate changes. While simpler to administer, be careful to not go wild creating Project Roles. Because members don’t carry over from one Project to another, having Project Roles with intuitive names for your

organization will make it easier for reuse. Using common names is especially important in helping lay out shareable Permission Schemes.

As a final note, try to avoid adding default members to Project Roles. If a Project Role has default members, those users will have that role in ALL Projects. This can lead to unexpected behavior and may cause administrative headaches.

Grow Your Knowledge

• Invest in training your admins—don't wait for admins to ask for this

• Use a lean approach to training teams leaders and users 

  • Train the trainers/internal champions
  • Lunch and Learns
  • Atlassian Community Events
  • community.atlassian.com
  • Atlassian Solution Partners (like us!)

   

• Ongoing Effort, not just a one-time even
  
  

Cleaning Up After Your Users

In general, cleaning up after deactivated users is not that difficult. Issues they have been involved in will still be in the system. The history of their work and their comments will remain. However, there are some areas that you should make sure you clean up as part of the offboarding process.

First, if they are the owners of any Projects, ensure those are transitioned to another user. Though this function does not have to be done prior to offboarding, it is a good idea to do it early so the Project continues unimpeded.

Next, validate that the user is not part of any Notification Schemes. This is especially important if you have granted access to external vendors. While employees that are no longer part of your organization may no longer be able to access their corporate email, third-party vendors may have had their notifications going to addresses that are outside of your control. There may also be places in your system where users receive additional notifications, because of Apps that allow for Workflow transitions to send notifications. You may need to track down these instances outside of the Notification Scheme changes. As with Projects, you can make these changes after offboarding, though earlier is better.

Finally, change the ownership of shared dashboards, boards and filters that belong to the deactivated user. This ends up being one of the biggest headaches when users no longer have access to Jira. If you don’t address this while the user is still in the system, you will have to use third-party Apps, database magic and complex admin processes to clean these up.

What's in it for the Users?

Scaled Jira configurations will result in a better user experience:

• Fewer fields to fill in = Better performance
• Fewer issues each user has to track = Better metrics
• Lower "switching costs" when moving from one team to another = Fewer requests for configurations changes
• More time to do work = Happier users