Managing queues at scale in Jira Service Management

[#1]

For any team in Jira Service Management Queues are the mission control for the project. As an Agent this is where you categorise effort, make prioritisations decisions, and launch into action.

As teams grow it is important for Project Admins to think about how they structure their queues so the team can be as productive as possible. This means managing load times, but also mental load.

Queues can be grouped into 3 sections within a project Starred, Team Priority, and Other. The former two will refreshed on a regular sync updating their issue count badge accordingly. The latter does not refresh, and is collapsed by default. For the best experience Agents should only see and refresh the queues that are relevant to them. You can learn more about these sections here. The total number of Queues are limited to 50 per project per work category (e.g. incidents vs. requests) across all sections (e.g. team priority vs. other). Any given queue will only refresh its count up until 999 issues at which point it will display 999+.

It is possible for regularly under-performing queues to present with a warning. You can continue to view these queues as normal, but their issue count will not be refreshed along with the other queues. Learn more about how this works here.

The following 5 scenarios are common queue configuration mistakes that lead to poor performance.

The “all issues” queue

Queues that attempt to return too many issues

These queues have often been there since the beginning of your project. They help small teams visualise and design a structure that helps them grow. But as the number of issues in the project and site grow these queues become a performance burden, especially when they are included in refreshing sections.

Recommendations

1. Delete or move to Other any queues that attempt to return all issues
2. Show only recent issues, e.g. use updateDate < 14d in your JQL
3. Use Filters for viewing / managing large issue sets

The “complex” queue

Queues that use very complex JQL

All queues utilise Jira Query Language (JQL), which is our proprietary language for querying issues. Similar to other database queries . Often it is better to have multiple simple queues than one complex one. You can learn more about optimising JQL in this article.

Recommendations

1. Avoid using excessive amounts of clauses and conditions
2. Avoid queues that analyse across multiple custom fields, complex functions, and/or labels
3. JQL clauses provided by Marketplace apps installed on your site can sometimes be problematic. Reduce their use if a queue is underperforming.

The “text search” queue

Queues that search text fields for keywords

It is possible to create queues that will perform full-text searches across issues. These queues perform on the fly categorisation, and might suggest room for improvement in your request structure. For example you might be trying to extract “summary ~ ‘hacked’” or “description ~ ‘component name’” or the worst of all “text ~ ‘thing’”.

Recommendations

1. Use request types and hidden fields to help customer categorise issues at point of creation, then build queues based on categories.
2. Automation rules to categorise issues (e.g. applying components or labels) then build queues based on categories.
3. Use Filters / Search for finding specific issues.

The “everything is a priority” queue

Having too many queues

It can be tempting to put all your queues into Team Priority. Data shows that on average an Agent views no more than 3 queues each week. So by prioritising all your queues, you are forcing every Agent to take on a lot of additional mental load, not to mention extra loading and scrolling which puts undue strain on the application and your Agents patience.

Recommendations

1. Start by moving all queues to Other. Encourage team members to Star the queues most relevant to them. Then consider which queues are critical to the success of your team (e.g. high priority, expiring SLA, and/or high impact). Gradually move these queues back into Team Priority.

The “not my” queue

Queues in Team Priority that are not for everyone

When faced with all the noise of a busy project it is not uncommon for individuals to create queues for themselves. Although this might boost their productivity, it will slow everyone else down who has to see and load a queue that is irrelevant to them.

Recommendations

1. Build queues that are dynamic. Utilise JQL functions like “currentUser()” to personalise queues to the individual.
2. Move unique or personalised queues to the Other section, and encourage Agents to Star queues that are relevant to them.

---

We are always looking at queues and how we can improve the experience for Agents and Admins. Do you have tips of your own? We would love to hear them. Drop us a comment below.

[Dave Mathijs]

Hi @Benjamin Paton thanks for sharing your tips and tricks and best practices on queues in JSM.

However, I never recommend using queues in JSM when there are dozens of support teams involved. Dashboards are way more flexible to use and can have multiple gadgets/filters on a single page.

Every support team wants filters based on different criteria.

Just as for filters and dashboards, there should be an option to create a queue and share it with a group or project.

I would love to see queues integrated with Teams in some kind of way.

[Dirk Ronsmans]

@Benjamin Paton 

Following @Dave Mathijs here.

While I try to make the queues as generic as possible so each team can view their own ticket sometimes Dashboards are just a lot more clear. (altho that brings another issue that people miss too much since a dashboard can get crowded quickly).

The best thing here would be to allow Queue visibility based on group membership (or other criterias)

(and in the end maybe multiple project queues :) but that's less used i feel and comes more down to an instance design mistake)

[Daniel Franz - JXL]

Great advice about Queues here Benjamin. In addition to the use of Dashboards recommended by Dave and Dirk, I'd also make a case for using Sheets.

If you're open to using apps, check out JXL for Jira. You can get a free trial on the Atlassian Marketplace. Full disclosure: I'm on the JXL team. Many of our customers use our app to replace or extend their use of JSM Queues, so I thought I'd share this here.

With JXL you can create full-fledged spreadsheets right inside Jira, with all the features you'd expect, like inline editing issues, copy and pasting fields, column sorting, filtering, freezing, table search, logical operators, JQL scope, full keyboard support, all fields supported, conditional cell/row formatting, cascaded issue groupings, hierarchy, field sum-ups, custom issue structures, etc.

You can easily create cross-project queues with Sheets and there are no limits for the number of sheets, columns, or issues. It's blazing fast at any scale.

[Carmen Nadeau]

We are using the addon Queues for Jira Service Management, it allows you to create global queues and it is not restrict to 1 JSM project. So we do queues that displays tickects associated to the current user/group for this agent.

The agent does not need to change project and can see all the tickects that his groups are responsable for in the same queue. It is easier for the agents

The goal of a Request Services Catalog is to categorize services logically and must not depends on the teams that will do those requests so this addon allow us to create queues allowing agent to see all their tickets.

Carmen

[Todd Thomas]

@Benjamin Paton

Like others have said, this is an excellent article! Our team reviewed our queues recently and have already adopted many of the suggestions you've provided. My feedback would be to provide some examples of queues to address those ideas you've provided.

We would like to utilize queues further, but since we have one project for a large team, we can't possibly create enough queues to satisfy each team's needs, and since they are limited to only being created and edited by admins, we've restored to relying on our staff to create their own Dashboards instead, like others have mentioned here.

Dashboards are much more flexible since they can be built off of whatever criteria you'd like using the Filter Results gadget. The biggest bummer, though, is the UI. Queues are updated more dynamically (versus 15 minutes on Dashboards at the fastest), and the presentation is much friendlier.

It's frustrating that if we want additional functionality for queues we need to turn to the Marketplace for apps. If Atlassian would like people to use the power of queues more, the system needs to be more friendly for customization and functionality.

[Benjamin Paton]

Thanks for the feedback @Todd Thomas

I assume the recent increase to 300 queues per project has been well received. 

Would you have individual team members able to create their own queues? When you say utilise queues further what do you mean?

I am sure my colleague @Ash Young would be keen to chat with you further about the gaps you need apps to solve.

[Todd Thomas]

@Benjamin Paton / @Ash Young -

Having additional queues is great! Our issue has less to do with the limitation on the number to provide and more to do with the administrative overhead. Our JSM team can't possibly anticipate or create all of the various permutations and combinations of issue management an agent might want to see in their queue. 

One of the most severe limitations now with queues is the inability to further filter/refine. Let me give you a use case:

Our help desk notices a variety of recent issues relating to a specific service (let's say a wireless outage). How can they easily find JUST those tickets in a queue? Today, they have to look through the list manually, select them, and take action. If they could instead filter based on some words or field values, this would aid in triaging them, both understanding how many issues are impacted and creating the ability to look for patterns or differences.

If we could set up some basic/generic queues and then agents could further filter them, that would help greatly. Being able to filter the options in a column and also refine through searches within that queue would help. Also, while there is some value in creating a static list of columns to display to create consistency, giving agents the ability to customize the columns shown would also be very useful.

Allowing agents the ability to filter and customize columns would be a significant improvement over the rigid configuration we have today that are completely dependent on the project admins. Perhaps we go the direction of Canned Responses and allow both public (admin only) queues and private queues that can be customized by the agents themselves? Allowing both personal flexibility and administrative control seems like a winning combo.

[Ash Young]

@Todd Thomas 

Thanks for the detailed write up - these are some very valid uses for search and filtering ad-hoc scenarios.

I'm definitely looking at how to scale how Queues should be governed when teams within JSM scale. I agree that having JSM's growth and expansion locked behind an admin creating a new queue isn't sustainable as organisations scale and more teams are introduced to the tool.

This is an area I'm actively exploring right now - If you're interested in sharing more, I'd love to jump on a call with you at a time that suits you?

Here is a calendly link to pick a time.

[Michiel Brand]

@Ash YoungDo you have an update on how to provide this feature: so to enable personal queues, which aren't displayed for all agents in the team - especially for environments / projects, where multiple teams are cooperating?

This would also be very useful for us, just as an example: IT-Sec and IT-Ops of course might have different preferences regarding the filter options. I know creating multiple projects can help there in some cases, but not in all; esp. the function of the default queue "My tickets" is almost obsoleted, when you start creating many different projects (which is another, but related problem).

Thanks in advance.