Using Jira as an incident management tool
Atlassian has an incident management tool in Jira Service Management. It makes it possible to report new incidents from inside and outside of your company. Incidents can come from an end-user or, for example, from a QA engineer in your company. There is a default Jira incident management workflow for handling the incoming incidents.
The default workflow is simple, as it only contains the crucial steps but is also flexible. You can customize it to your own needs.
There are many sources provided by Atlassian to learn from and train your employees. There are incident management getting started guides as well as Team Playbooks to educate your team on how to handle incidents.
Jira Service Management is compliant with the ITIL guidelines for incident management. It also provides useful default fields for incidents, including "Impact", "Severity" and "Urgency". On top of managing incidents, you have options to generate incident reports with dedicated reporting apps like Better Excel Exporter.
Here we examine the default Jira incident management workflow and clarify the difference between incidents and problems. This article also looks at what a blameless postmortem is and offers options for Jira Service Management Excel reporting.
A simple Jira incident management workflow
As we mentioned above, there is a simple default workflow. The Jira incident management template doesn't use any special statuses, and it complies with the ITIL recommendations. We will break it down now, which helps you understand and fit the workflow into your incident management process.
Jira incident management workflow statuses:
- Open. Open status corresponds to the creation of an Incident. It is reported either by end-users, monitoring systems, or internally.
- Assigned. This is not a separate status but the assignment is significant in incident management. The assignee’s task is to categorize the incident and consolidate different incident reports. An assignee also sets the priority of the incident according to its impact and urgency.
- In progress. Investigation of the affected services, potential causes, and recommended solutions to the incident. Gathering more information from the reporters, users, DevOps, etc.
- Pending. While waiting for information from other teams or external sources, the incident can be in Pending status.
- Resolved. When the team implemented and released the solution, and verified that it works, the incident is resolved. Depending on your team preference, you can continue to do a PIR (Post Incident Review).
- Under PIR. A Post Incident Review (PIR) like a blameless postmortem helps uncovering security holes and vulnerabilities in your products or services. The findings should feed back into your development process to ensure that critical fixes are implemented in upcoming sprints.
- Closed. When no further investigation is planned, the incident goes to Closed.
Difference between problems and incidents
The Jira Incident issue type can cause confusion. First of all, incident management is part of Jira Service Management and thus uses request types instead of issue types. The IT Service Management projects include the appropriate request types by default.
There are two incident management-specific request types: Incidents and Problems. An Incident is a one-time disruption of service. Incidents are not your common bug, they make the service partly or entirely unusable for part or the entirety of users. It involves security breaches as well that compromise sensitive customer data.
Noteworthy incidents
Remember GitHub's recent security incident? An attacker abused stolen OAuth user tokens issued to two third-party OAuth integrators to download data from dozens of organizations. That was a security incident.
In another case of service degradation, Xbox had a rough weekend. For about 36 hours in mid-May, Xbox players had trouble connecting to the Xbox network. The digital service outage even affected offline games. Players were not able to play offline with games they purchased online. That was a serious service outage.
A problem is the underlying cause of these incidents. You can have problems in your system which can cause one or more incidents before they are uncovered and finally fixed. An incident can have more than one cause, thus more than one problem can be associated with it.
Review and testing processes can reveal potential problems before they can cause an incident. Problems can be software bugs, poor planning or even lack of communication between teams.
In Jira Service Management you can use one type of problem and two types of incidents for the service requests. For problems, create an "Investigate a problem" service request. For an incident, you can use "Report a system problem" or "Report broken hardware" request types.
According to the ITIL guidelines, you should manage problems and incidents separately. You can read about this in more detail.
Blameless postmortem
Problem management and incident management should be separate, and a blameless postmortem helps the two teams to share the necessary information. Atlassian’s advice is to use the practice of blameless postmortem after the incident is resolved.
A blameless postmortem aims to investigate the underlying problem(s) behind the incident and not to find who did something wrong. Teams use the blameless postmortem to improve their processes and resolve the root cause, preventing the same incident from happening again.
The incident management team reviews the incident, how it was handled and investigates the root cause. They can do this alone and give their findings to the problem management team or the two teams can do it together. Working together is more effective in making sure that no information is lost. This is how blameless postmortem helps to spread the necessary information and the discovery of the root cause(s) of incidents.
Create a Jira Service Management incident report
Reporting on incidents and problems in your Jira Service Management can help you analyze different aspects of what is happening. Better Excel Exporter's built-in Incident Categorization Report is a useful tool to make blameless postmortems easier.
You can export the Jira Service Management incident report by following these steps:
- Go to the Advanced issue search in Jira
- Filter the Incidents you want to see in your report
- Select the Better Excel Exporter icon at the top
- Select the Incident Categorization Report
Better Excel Exporter’s Incident Categorization Report will contain the incidents you’ve included in your search. It creates pivot tables and pivot charts aimed at Product and Operational Categorization reports.
If the automatically created charts don't fit all your requirements, you can easily make changes. Select other fields in the pivot table and chart and make it focus on the metrics you need.
You can glean insights regarding for example:
- Which of your systems and services are affected by incidents the most?
- What services caused incidents with the widest impact?
- Which operation was used the most to resolve the incident?
- Are the majority of incidents reported internally or externally?
- Where are those reports coming from exactly (e.g. the testing team or the performance monitoring system)?
Answer your Jira Service Management incident management questions with best-of-class Excel reports! You get the built-in Incident Categorization Excel Report when you start a free trial of Better Excel Exporter for Jira Cloud!
Create your Jira incident management report!
