ServiceClarity provides a set of unique data collectors specifically for working with your JIRA data. These range from simple issue counters to time trackers and also more specialised JIRA ServiceDesk SLA trackers or JIRA Agile Story Points and Epics. The value that these ServiceClarity JIRA data collectors provide builds upon the JIRA’s own query capabilities: the JIRA Query Language (JQL).
ServiceClarity leverages all of the power of JIRA’s JQL search to ensure that your ServiceClarity KPIs are tracking just the right JIRA issues, enabling you to track specific projects, user groups, status changes, SLAs and Epics. In fact anything that you can find in JIRA can be tracked in ServiceClarity by adding the JQL query to the ServiceClarity data collection configuration:
If you are unfamiliar with JIRAs search capabilities we suggest experimenting with JQL from the JIRA application. You can enable JQL search on the Issue Search page in the JIRA application to try out the powerful query language:
Once enabled the JQL search capability in JIRA provides advanced searching. JIRA JQL queries created within the JIRA application can be copied directly in ServiceClarity and used to build ServiceClarity KPIs.
Comprehensive reference material on how to the get the most out of JQL is provided by Atlasstian on their support portal. We recommend the following Atlassian guide and reference documents:
- Getting Started - https://confluence.atlassian.com/jiracorecloud/searching-for-issues-765593657.html
- Advanced Searching - functions reference: https://confluence.atlassian.com/jiracorecloud/advanced-searching-functions-reference-765593719.html
- Advanced Searching - operators reference: https://confluence.atlassian.com/jiracorecloud/advanced-searching-operators-reference-765593718.html
How to find the data you need
When creating ServiceClarity KPIs from JIRA data it pays to be as specific as possible with your JQL queries. This is true regardless of what you are asking ServiceClarity to track: time spent, issues closed, SLAs breached, total estimated effort, etc. The values for all of these KPIs can be affected by the selected set of JIRA issues. It is important to make sure that ServiceClarity JIRA data collection tracks the right project, the right issue type, priority and status.
For example, an important KPI available from JIRA, and a fundamental performance indicator, is a count of the number of tasks (issues, tickets, stories, etc) that are actively being worked on at any one time. This is the simplest measure of work in progress (WIP) that you can track and in the absence of detailed estimates or sizing it can be a valuable way to monitor the flow of work. The default JIRA installation and JIRA Cloud account come with a built in configuration that includes a work status called: “In Progress”. To make use of this default we could write a JQL query to find work that is currently “In Progress”:
status = 'In Progress'
Every time this JQL is run it will return the set of tasks in JIRA that currently have a status of In Progress. However, many JIRA systems contain data for multiple independent projects and the above JQL will find all tasks in all projects. We can refine this query to include only those tasks that are in a specific project:
status = 'In Progress' AND project = 'Example Project Name'
The above is a more specific query but it might still not be targeting the exact set of tasks that you want to track in ServiceClarity. For example, it is common to configure JIRA to manage multiple types of work including but not limited to: customer support issues, defects (or bugs), ongoing production tasks, design tasks, agile stories and many more. We can further refine our In Progress JQL to filter out one or more of these types:
status = 'In Progress' AND project = 'Example Project Name' AND issueType = 'Defects'
Hopefully it is easy to see how the JQL query for our work in progress KPI can be evolved to focus in on a specific area of interest.
Start using ServiceClarity alongside JIRA today!