Cycle Times with JIRA

Cycle Times present really interesting insights into how your team is Jira delivering and can highlight any potential bottlenecks in the flowprocess as well as serving as good benchmark for the team.

Additional Insights

If you want further insights into Lead Time and Cycle Time. you should look into: https://kanbanize.com/kanban-resources/kanban-software/kanban-lead-cycle-time

Ingredients

• Jira

Cycle Time with Jira Reports

Jira comes with a report type called “Control Chart” which is used to see a boards cycle time and to get an overview based on a timeline how all of the tickets have been progressing.

Here is an example of how a Control Chart looks like:

It can look rather confusing but actually, once you understand the various elements its very initiative.

How to find the Control Chart Report

Follow the below steps to get to your Control Chart Report

1. Navigate to your Jira instance
2. Utilising the “Projects” area in the navigation bar, select the project you’re interested in the cycle time for
3. Once you’re in the correct project, select the correct board for the cycle time you would like to see
4. Now that you’re in the correct board, on the left vertical navigation pane at the top, you will see a bunch of options like “Backlog”, “Kanban board” and “Reports”. Click on the “Reports” option
5. You will then be taken to an overview of the various reports available for that project and Jira itself. Click on “Control Chart”
6. Hey Presto! You’re there

How to read the Control Chart Report

Below are some insights on how you can utilise the information on the Control Chart to find the Cycle Time and to understand any additional instruments.

Cycle Times & Other Metrics

This is how you can find out the current Cycle Time as well as a breakdown of other metrics which maybe be of interested

Below is a breakdown of the various metrics:

• Cycle Time – This is the main metric you should focus on. This is the average cycle time
• Median Time – This shows information on the ticket from the exact middle of the pack of issues
• Minimal Time – This shows the fastest time for a ticket to go through a cycle
• Maximum Time – This shows the longest time for a ticket to go through a cycle
• Number of tickets used to generate the metrics. This is from the board’s filter

Tickets to Investigate

One thing that could be worthwhile investigating are the tickets which are outliers.

You can click on the individual green dots to gain insights into which ticket it was and its recommend to look into it to see if there were any special cases with that specific work unit. There can be and it’s normal to have some work units which are outside the “normal scope” in terms of Cycle Time but it’s just something to keep an eye on.

Cycle Time Trending

One area which is recommend to keep an eye on roughly a monthly basis is the “rolling average trend line” this is the blue line in the report

If you see the blue line trending upwards, this is the best time to investigate why this might be happening. It could just be that larger work units are coming in for a big project and it will stabilise but this is a could health indicator when it comes to Cycle Time for the team.

Filters to be aware of

You are able to tweak what options are considered when building the Control Chart. This maybe helpful to define the attributes based on how your team is working.

Below is a breakdown of the various filters available for the Control Chart:

• Time Scale – Here you’re able to define the length of the timeline from a timeframe perspective (last month, last 3 months etc) or from and to specific dates. This could be interesting if you just want to observe the cycle time from a specific project the team was working on
• Refine Report – Here you can define the specific statuses of the tickets in the report as well as refine the issues further by utilising a quick filter. I would only recommend a quick filter if the board’s filter you’re looking at is not adequate
• Viewing Options – By default non-working days are not considered, this is a configuration in Jira and by default Saturday and Sunday are not defined as working days (this can be configured)