Geek Culture
Published in

Geek Culture

How to Hack JIRA to Measure Cycle Time in 4 Easy Steps

What is Cycle Time?

Cycle Time, the time it takes for a user story or other task to go through the software development lifecycle, is a common metric used in Kanban. It replaces velocity as a measure of efficiency and predictability for a team.

An example kanban board from Atlassian
Image Credit: Atlassian — Agile Product Management

If we consider the very simple JIRA Kanban board above, cycle time would measure the time it takes for a story or task to move from In Progress to Done.

Why is cycle time better than velocity for measuring the predictability of a team?

Predictability is an important goal of any agile team that serves business needs. We cannot coordinate a product launch or hit quarterly goals without some level of understanding of how long the work will take. The traditional agile method for measuring predictability is velocity. Velocity depends on story point estimates made before work starts using our best guess of how the work will be completed. Velocity is based on wishes and hopes, easily manipulated to make the most unrealistic timelines look achievable if only the team would stay on task. Even the best teams will occasionally get their story point estimates very, very wrong, and unexpected time off or unexpected bug can throw the team’s velocity into a tailspin.

Cycle time learns from reality. It removes the wishes and hopes and presents the team with the cold hard truth of just how long it takes to complete an average story. Coupled with throughput, the size of the backlog, and an understanding of how often new work interrupts your roadmap, teams can use cycle time to get a much more accurate prediction of when work will be completed. Because cycle time measures what happens in the real world, not just a hand-wavy estimate of what we think will happen in ideal conditions, we can also use it to set goals for our team’s efficiency, driving continuous improvement and iteration. For more information on how to leverage cycle time, I recommend the Agile Alliance’s case study on kanban methods and metrics.

How JIRA’s Out of the Box Solutions Fail

Despite cycle time’s growing popularity, JIRA has not provided a solution for agile practitioners that measures cycle time effectively. JIRA has two main ways of attempting to give users this data: time in column indicators and the control chart.

Note: There are a few JIRA plugins that promise to measure cycle time. Full disclosure: I’ve never tried them. I didn’t see the need to pay for a plugin when there’s a pretty easy solution using base functionality.

Time in Column Indicators

An example Kanban board
See those tiny little dots? Yeah… I don’t either.

Time in column indicators are enabled for a JIRA Kanban board by going to Board Settings -> Card Layout.

Days in Column configuration in JIRA Board Settings

The help text promises that days in column indicators help identify slow-moving issues. Sounds great, right? They would be if there were any rhyme or reason to when a new dot is shown, what colors the dots are, or anything else about this visual indicator. As you can see in my example above, JIRA decided to show 3 dots (two grays and one yellow) for an issue that has been hanging out in QA for 4 days (I agree that’s too long, but it’s a Monday and our QA is out — give us a little slack). These little dots are also not aggregated in any way to show the team’s progress at keeping tickets flowing week over week. Even if we could get the visual indicators figured out, without a dedicated report these are just vanity metrics to identify individual problem issues.

Control Chart

That brings us to the Control Chart, JIRA’s sloppy attempt to measure the cycle time of a team.

An example JIRA control chart

From JIRA’s Control Chart support documentation, we learn that

The rolling average (blue line on the chart) is issue-based, not time-based. For every issue shown on the chart, the rolling average (at that point in time) is calculated by taking the issue itself, X issues before the issue and X issues after the issue, then averaging their cycle times. 20% of the total issues displayed (always an odd number and a minimum of 5 issues) is used in the calculation.

Therein lies the problem with the Control Chart: this rolling average based on X issues before and after renders the metric all but useless. Instead of a metric we can check in on every week and depend on the number for 3 weeks ago to remain the same for every week following, you will regularly see the number improve or decline after you’ve reported on it each week or sprint. This rolling average calculation also means that changing the time frame of your report will dramatically influence the results. While the control chart does do a good job of visualizing outliers to spark conversation, using it to actually track and decrease cycle time is a frustrating proposition at best.

The Solution

With a few minutes of setup and minimal effort each iteration, you can have a much more useful cycle time metric for your team. All it takes is a little bit of JIRA-fu and pivot table magic.

Step 1: Create a custom field as your Cycle Time Start Date

Follow the Atlassian Support Documentation to create a new Cycle Time Start Date field and add it to the field configuration for any relevant issue types you want to track. For my team, we added the new date field to Story, Bug, Spike, and Task and hit it from all create and edit screens.

Step 2: Set the custom field as a post-action on the relevant workflow transition

JIRA workflow post functions perform additional actions after a workflow step has been completed. These little unsung heroes are perfect for setting the date an issue transitioned to In Progress (or whatever status makes the most sense for your team) to start measuring cycle time. Read more about how to set them up in the support documentation here. In the screenshot below, you can see how. I’ve configured my workflow step to automatically set my custom Cycle Time Start Date to the current date time.

Configuring a JIRA workflow to add post functions

A note on transitions: My example above has a flaw that may or may not affect how you want to measure things for your team. Because this post function will be run every time an issue transitions to In Progress, it will override previous values if an issue returns to In Progress from Code Review or QA. To prevent this, update your workflow so it doesn’t reuse this transition and only set the post function on the appropriate transitions.

Step 3 — Export a report from bulk issue search

After you publish your workflow changes, you’ll want to wait a few days or weeks for data to accrue. Once you have enough to satisfy your reporting granularity, it’s time to get busy with JIRA’s Advanced Issue search functionality. You’ll want to save a filter for this to ensure consistency. My example query grabs all issues of type story, spike or bug, resolved in the past 180 days, within my project. I then set the columns to show the cycle time start date along with resolution date, issue id, assignee, and anything else I may want to report on. Note: my team is in a transition phase between sprints and kanban, so despite their flaws, we do still estimate in points. Comparing the point estimate to the cycle time has been a very interesting exercise in showing just how inaccurate our estimates are.

My JIRA Advanced Issue Search

Export this report and then import it into your spreadsheet application of choice.

Step 4 —Set up your pivot tables and charts

Google Sheets is my preferred spreadsheet application. After importing my raw JIRA .csv into a new sheet, I added two new helper columns: Cycle Time Days and Week Number.

Cycle time is the number of days between Cycle Time Start Date and Resolution Date. In Google Sheets, this can easily be done with the formula =days(Resolution date, Cycle Time Start date).

Week Number helps me report this on a week-by-week basis without having to fight with the pivot table date fields. It’s optional if you have more weekly pivot table reporting skills than I do. It can easily be calculated in Google sheets by =weekNum(Resolution date).

Next, I set up a pivot table with week num as the rows, issue type as the columns, and the average of cycle time days as the values.

Once I got the pivot table set up, it was easy to turn the data into the graphs below:

A chart of our cycle times year to date
Cycle time in days for all issue types, year to date


As you can see, it’s easy to get JIRA to show you a detailed cycle time metric. You can customize this process to show lead times, only the time spent in QA, or any other relevant status(es) you want to measure going forward. For updated numbers, just export the data and update the pivot table and chart whenever you want to report on the metrics. If you were really savvy, you could probably get JIRA to automatically email this to you and Zapier to generate the google spreadsheet. Maybe I’ll investigate that for a future article, but right now my team needs me to investigate the bottlenecks that have been causing our cycle times to spike dramatically every few weeks.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Abby Allen

Abby Allen


Abby Allen is a user-focused product manager, engineer, entrepreneur, and mom based in Minneapolis, MN.