Best practices for scaling Jira Software

In this guide, we'll look at the best ways to use Jira Software for both large organizations and teams that wish to scale. If you have a large Jira instance with multiple Jira applications, then you'll want to start with Performance and scale testing, which shows the performance of Jira Data Center and how different factors and data sets (issues, users, attachments, etc.) affect it.

This page will provide specific information about scaling the Jira Software application.

Board design and usage

There are a number of things to keep in mind when configuring boards for scale. Not only can you include issues from multiple projects, but you can also exclude issues based on JQL - this can lead to confusion of what is and is not appearing on the board. Generally it's best to start off thinking about the true goals of this board. Keep in mind, you can create multiple boards (even multiple boards that cover the same issues) to show data differently for different teams.

Whenever you create a new board using the Scum or Kanban presets, a corresponding filter will be created for you as well - this means you can modify the filter to narrow down the issues on the board, removing those you don't need to see and letting you focus on only what you need.

It's important to note that while boards can display up to 2,000 issues, it's not recommended to be viewing that many records on the board at once. Boards that have 500 or more issues to display will take a longer time to render in some browsers (IE8 for example) or on lower powered machines (see the bottom section on Client Side Considerations for more info). Additionally, it can be difficult to find the issues you want in a sea of cards. Additionally, your Jira instance will need to pull up the data about these issues at each refresh - if there's a thousand issues there and 25 people want to load this board at the same time, then there's a bit of work to be done there.

The issue data itself is pulled from the indexes with the new boards, rather than from the database directly, so this should greatly improve the load times you'll see on larger boards. This should also be taken into consideration when scaling a Jira instance.

Since boards also inherit the permissions of the filters they are based upon, it's now possible to create boards visible only to certain groups or roles, to help alleviate the clutter you might otherwise see when trying to find the right board.

Cutting up the workload

If you find you have an overwhelmingly large board then usually the first place to look is the quick filters. Quick filters allow you to narrow the board down to a subset of the issues that match both the original filter and the quick filter. Often we've seen large boards with a number of quick filters that could easily be broken down into two or three smaller boards. Start by looking at the quick filters that are used most often and look at what they focus on. Also take a look at filtering out issues that are stale. If an issue has been sitting around for over a year without an update, what kind of value is it providing to anyone? Perhaps setup a second board that collects all the old, out of date issues and occasionally triage these closing them off or updating them (promoting them to the primary board).

JQL allows you to search by a wide variety of aspects of the issue - assignees and reporters (both individuals and groups), issue age, time since last update and of course the historical searches allowing you to see things that at one point in time were in a particular status, assignee etc. By focusing on the particulars that make issues important to you, it will become much easier to get a board with exactly the issues you need.

Once that initial filter is built there are a number of ways to increase focus on the issues you need:

• Swimlanes allow you to set the order of certain issues based on the JQL you need. For example, you may want to see your issues organized by priority, promoting criticals and blockers to the top. Alternatively you might want to organize it by assignee so you can see who is doing what.
  
  
• Quick Filters are great for quickly grabbing the issues you need such as your assigned issues, or only the recently updated issues so you can see what's changed since yesterday.
  
  
• Card Colors allow you to customize the colors of the cards on your board either based on issue type, or arbitrary JQL so you can highlight issues of importance.
  
  

How Atlassian uses Jira Software

Within Atlassian we have quite a number of small teams, but we do have two particularly large teams that have each had a different focus and way of handling issues - as well as dramatically different Jira instances.

Within Support, we run a Kanban style board that we have broken down into smaller individual boards based on the regional teams we have. Since we do not rank issues within Support (instead going on a first in, first out basis after priorities are taken into account) we have decided to change our filter to not Order By Rank, instead we order by a combination of priority and time in status.

In addition to this, we've heavily customized the Swimlanes to promote Escalated tickets, Critical Issues, Enterprise and unassigned issues higher than non-critical or already assigned issues, allowing us to quickly scan the top row for the most important issues all the time. After that we have each individual engineers workload visible which allows us to quickly determine who can take on the next issue.

On the other hand, the Jira Development team has broken themselves into smaller sub teams based on the themes of the work they are doing. This allows them to individually have their own boards on a per team basis, while the Product Managers use an aggregate board of the Stories to see the work being done by each team. By focusing on the bigger picture, they can simplify the board and summarize where everything up to, as well as quickly see which teams have the most stories to work on.

Client side considerations

Since the new boards are now doing a lot more work client side than they used to, you may find that when you first upgrade that some users on older browsers or lower powered machines are experiencing slower load times. Cutting down the board size or reviewing the browser type and client machine specs will help alleviate these issues.

Atlassian  Long Term Support releases

An Atlassian Long Term Support release is a feature release that gets backported security updates and critical bug fixes during its entire two-year support window. If you can only upgrade once a year, consider upgrading to a Long Term Support release. Learn more

Work with our Solution Partners

Especially when your Jira Software has reached a more advanced size and complexity, we would recommend to collaborate with one of our Solution Partners.

We can help connect you with a right Partner.  If you're interested for a referral, please contact us.