At the recent Atlassian Summit 2010, we demonstrated the homegrown tool that Atlassian’s global Technical Support team uses to manage our shared support queue. In part 1 of this blog series, we’ll cover why we needed a new tool, and the concepts behind the shared view we built. In part 2, we’ll break down how we turned our best practices and ideas into a working tool that we plan to eventually release as a JIRA plugin.
Part 1: The Challenge of Working from a Shared Queue
In Atlassian, we use our issue tracker JIRA for customer support and as a customer help desk tool. We use JIRA to handle customer problems reported to our support team, and we have a shared queue for each of our products. All of our engineers take issues based on the products and customer time zones they cover. When I started at Atlassian, the support team was using saved filters and dashboard gadgets to display a list of incoming issues that needed attention. Issues were displayed in the order received in a simple “first in, first out” view. Each engineer looked at a dashboard with 4-5 gadgets and decided what to work on based on their personal understanding of the team goals.
The issue navigator view allows an engineer to review a list of issues sorted according to simple fields.
Last year, we made a plan to introduce guidelines to let customer know how long they should expect to receive an initial response. The response times are based on the severity of the issue (how bad is the problem, how many users does it affect). These goals are:
||Initial Response Within
| Production application down, or major malfunction causing business revenue loss or high numbers of staff unable to perform their normal functions.
|| 1 working hour
| Serious degradation of application performance or functionality.
|| 4 working hours
| Production application issue that has moderate impact to the business.
Need assistance with installation or upgrade.
| 8 working hours
| Question on how a particular feature or function performs or should be configured.
|| 24 working hours
In order to meet the goals for initial response times, an engineer would need to:
- Start with the filtered list of incoming issues
- Look at when the issue was created
- Calculate how long the issue has been waiting
- Decide which issue to work on based on which one is closest to the goal
With the existing dashboards, a support engineer had to do a bunch of subtraction in their head, take a few notes, and then compare the numbers for each issue to the goals and then to each other. Our goals were clear, but there was too much mental effort required to meet them with the existing tools. What we needed was a tool that would:
- Do all of the calculations about “time spent waiting”
- Take our best thinking about what issues need to be addressed first
- Put that into a form that was clear to every single engineer.
Our Solution: A Shared View of the Shared Queue
The shared view of the same issues pictured earlier in the issue navigator.
We started work on a shared display, a view of the shared queue that was designed to be mounted on a large display on the wall of the support area. This view needed to balance the different roles within the teams and give everyone a shared understanding of the queue that could form the basis for daily decisions and discussions.
Our initial efforts were based on the use of the combination of Confluence plugins discussed in detail in my colleague Jim Severino’s excellent blog series “Confluence for Business Intelligence“. Central to this approach was a massive SQL query based on a deep understanding of JIRA’s database schema. We were able to incorporate a lot of the business rules into pure SQL thanks to the support for case statements built into PostgreSQL and a liberal sprinkling of subselects. The SQL query returned only the issues that were “in scope” for a team in the order in which they should be handled.
Issues are color coded by urgency, with the most urgent issues at the top. Issues move to the top as they become more urgent.
The results including hints that were used to color-code the issue according to its urgency. The most urgent issues are displayed in red, the next most urgent are displayed in yellow, and so forth. As time goes by, an issue increases in urgency until it reaches the top of the board. Within each color band, issues are sorted by severity, and then by time spent waiting. Engineers work from the top of the board, so that the issues with the most urgent need always get attention first.
More urgent issues move up the queue more quickly than less urgent issues.
The first shared queues had a huge impact. Suddenly, an engineer could look over and decide what issue to take next at a glance. It also put all of the teams in our global offices on the same page. If someone on the team in Amsterdam said “is anyone working on the critical at the top of the queue?” on the group chats, engineers in the other offices knew exactly which issue they’re talking about. This gave us a shared understanding of the queue, so that we could decide as a team how to divide things up. Best of all, as our process of handling the queue changed, we had a single place to visualize the current best practices.
In part two of the series, you’ll learn how our support team sat down, documented our best practices, and wrote the code behind the shared view that helps us meet our goals.