Unless your JIRA system, or project, has recently been created it will very likely contain a wealth of historical information. For ServiceClarity to build a historical view of your data it is often necessary to rethink how you find the issues that you want to track, to rethink your JQL. This can be best explained through a simple example: work in progress

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' AND project = 'Example Project Name' AND issueType = 'Defects' 

The example query above will return the issues that are in progress at the moment the query is run, however, for ServiceClarity to look back in time at historic JIRA data we need to rethink how we select the work in progress. Fortunately there are advanced JQL features that can help us, the details of which can be found in Atlassian’s support portal:

Using the advanced JQL operator WAS … ON  we can adapt our previous example to cope with finding historic data by changing the date ‘2015-11-14’ in our new example JQL:

status WAS 'In Progress' ON '2015-11-14' AND project = 'Example Project Name' AND issueType = 'Defects' 

The Atlassian documentation on advanced operators includes many examples but an interesting one worth highlighting here is CHANGED FROM … TO , which can enable some useful JQL filtering within ServiceClarity. 

An example of how ServiceClarity can make use of this operator is to historically track a common support KPI: time to respond. This KPI calculates the time that support issues take to move from a status of “New” to the next stage of the support process, for example: “In Progress”. To calculate values for the time to respond on a date in the past ServiceClarity needs to find those issues that have made that transition from “New” to “In Progress” on that date:

status CHANGED FROM 'New' TO 'In Progress' ON '2015-11-14' AND project = 'Example Project Name' AND issueType = 'Defects' 


Did this answer your question?