Application for JIRA data analysis

Last updated: Dec, 31st 2011

download: source(Python script), source(GnuPlot script)

Description:

JIRA is used to log our incidents for on call (piquet). The on call team covers several domains and subsystems. The "components" field in JIRA is used to designate the subsystem to which the incident relates. It provides us with sufficient information to generate reports.

For our on call (piquet) we wanted to have an overview of not only the issues per week, but also issues per week per component, issues per month per component, number of issues per component, issues per hour of the day, issues per day of the week, and some various other statistics related to the person on call (piquet).

JIRA has some possibilities to generate plots from the issues logged and most of these statistics can be plotted within JIRA, however it can be cumbersome to create the necessary filters and it takes time to plot them. Furthermore, since not all these statistics can be easily generated with JIRA there is still some "manual" labor needed to visualize the remainder of the statistics. A Python script was developed that would use the generated XML from a JIRA export and create a set of data sets that can be visualized with GnuPlot. Below are several plot results based on the scripts. With GnuPlot we created bar graphs that splits (using different colors) the incidents in their various components.

Incidents per component
Figure 1. Number of piquet incidents per component.
Incidents per day of the week
Figure 2. Number of piquet incidents per day of the week.
Incidents per hour of the day
Figure 3. Number of piquet incidents per hour of the day.
Incidents per week per component
FIgure 4. Number of piquet incidents per week per component.

Using these plots we gain better insight into the incidents and associated components. It enables us to strategically take action, if we detect a high incident rate per component. Two "special" components where defined.: 3rd Party and User-Error. Not all incidents that are dispatched to the piquet team are the result of a system malfunction. Sometimes the user makes a mistakes but does not realizes it. Other incidents can be dispatched to the wrong piquet team. Whenever this happens our piquet team will register these incidents as either 3rd Party or User-Error. It enables us to visualize what is the ratio of incidents not related to our piquet team and allows us to alert groups to train users better.

Based on the plots shown, several observations can be made: Figure 1 shows that two components represent the majority of the incidents. Figure 2 shows that on Saturday and Sunday we have more incidents than during the weekend. This is not surprising as the piquet period during the weekend is longer. Figure 3 shows that the incident rate is highest between 19:00 and 23:00. This is also not surprising as during this period many shows that have just been broadcasted (prime-time) are prepared for on-line viewing. Similarly there are less incidents between 16:00 and 17:00 as not many shows are prepared. Figure 4 shows that at the beginning of the year there was a relative high incident rate for one component (yellow). When this was detected measures were taken to improve the stability of this component, resulting in a reduction of incidents during the remainder of the year.