Improving your triage for better incident management in Jira
This is the second in a series of blogs aimed at making your incidents smoother, quicker and your customers more satisfied. We’ll bring you tips and best practice based upon real-world engagement with many users of both Jira Software and Jira Service Desk.
First, let's do a quick health check of how our incident management process is handled. To understand where we are, ask the following questions of your current process:
- How effective is the triage team when a new incident or alert arrives?
- How long does it take the team to identify possible known problems?
- Can the team quickly see a list of items awaiting triage?
Please note that our next set of tips use both Jira Software and ScriptRunner for Jira to help with improving your triage.
How should we visualise triage?
Visualising your issues can be one of the easiest ways to improve your triage. In Jira you can create a Kanban board which provides a quick overview of the current situation.
Which issues should be shown on the board?
Depending on your business needs, your Jira instance and projects can get really cluttered with a huge number of issues. How do you ensure that your triage Kanban board only shows the issues that your team needs to focus on?
Firstly, assess what types of issues you want to prioritise. The triage team needs to have quick access to current incidents or alerts - the known and recent problems - and any outstanding remedial actions. To read more about these four issue type, read the first blog in this series. To get to this view, we need to build a filter for our board. In your Kanban board you need to add the following JQL.
project in (PM)AND ((issuetype in (Incident, Alert, "Remedial Action") and resolution is EMPTY) OR (issuetype=Problem and (resolution is EMPTY OR resolutiondate > -7d))) ORDER BY Rank ASC
To understand this query let's break it down into its constituent parts:
|project in (PM)||Restrict our board to the projects managed by the Triage team Note: You should change this to include the appropriate project codes for your installation.|
|(issuetype in (Incident, Alert, "Remedial Action”) and resolution is EMPTY)||Find all the unresolved Incidents, Alerts and Remedial Actions|
|(issuetype=Problem and (resolution is EMPTY OR resolutiondate > -7d)||Find Problems that are unresolved or recently resolved (within the last 7 days) Note: You can change the 7d to reflect a different period based on your own requirements.|
|ORDER BY Rank ASC||If you use global ranking this makes sure your Kanban board reflects the ranking of the issues.|
If you use global ranking this makes sure your Kanban board reflects the ranking of the issues.
Grouping issue types together
To help the triage team respond to the highest priority issues, we can group the different issue types together. We can also promote any issue to the top of the page if it's been flagged.
We use Jira's swimlanes to group issues. In the diagram above you can see five collapsed swimlanes relating to the four issue types and the flagged category. To build the swimlanes we need to define some JQL to each swimlane:
|Flagged||Flagged is not EMPTY|
|Problems||issuetype = Problem|
|Incidents||issuetype = Incident|
|Alerts||issuetype = Alert|
|Remedial Action||issuetype = "Remedial Action"|
To flag issues we've used the standard Jira flagged field to highlight any particularly problematic items. In a future blog we will take a look at how the flagged field can be automatically set when an issue is approaching an SLA deadline.
How do we view the known problem list?
Now that we've created our swimlanes, we could just look at the first three columns of the problem swimlane. These are issues that are currently in the backlog, selected for development or in progress (see the first image in the blog), however we can improve this view. All we need to do is add another quick filter that returns all unresolved problems. To do this we need to add the following JQL to the Kanban board:
|Open Problems||Issuetype = problem AND resolution is EMPTY|
This is a great view for anyone who wants to see what is already in hand, what is marked for resolution and can be used as a quick reference point.
But triage is different
To give the triage team the ability to make the best decision on issues that come in, we need to allow them to view new incidents and alerts with both unresolved problems and those that have been recently resolved. We do this by adding the following JQL to the board:
|Triage||(((issuetype in (Incident) AND NOT issuefunction in haslinks("Incident of Problem")) OR (issuetype in (Alert) AND NOT issuefunction in haslinks("Alert for Problem"))) AND resolution is EMPTY) OR issuetype = Problem|
Diving into this query, those familiar with JQL might notice that there are a few parts that aren't standard. The above query uses ScriptRunner for Jira's JQL extensions, let's take a look at what each part does:
|issuetype in (Incident)||This matches any issue of type Incident|
|issuefunction in haslinks("Incident of Problem")||This checks to see if the issue has any links called “Incident of Problem”|
|Issuetype in (Incident) AND NOT issuefunction in haslinks("Incident of Problem")||By combining these two conditions we match all Incidents that are not yet linked to a Problem ticket|
By combining these two conditions we match all Incidents that are not yet linked to a Problem ticket.
The next blog will look at how you can quickly link a new incident/alert with a known problem. In the meantime, check out the first blog in the series or, if you don't have ScriptRunner for Jira yet, start a 30 day trial via the Atlassian Marketplace.