Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,361,493
Community Members
 
Community Events
168
Community Groups

Managing queues at scale in Jira Service Management

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.

image-20220823-065825.png

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.

4 comments

Dave Mathijs Community Leader Aug 11, 2022

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.

Like # people like this
Dirk Ronsmans Community Leader Aug 16, 2022

@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)

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.

jxl-demo-cloud-view-v5-sm.png

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.

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

Like # people like this

Comment

Log in or Sign up to comment
TAGS
Community showcase
Published in Jira Service Management

An unofficial way to monitor a JSM mail handler for errors

...eturns true if any content is returned for the webResponse.body.data.first s...

716 views 3 20
Read article

Atlassian Community Events