Metrics Reports for Kanban: Lead Time/Cycle Time/Throughput

[Evelyn Dieppa]

Hello!

I have just started measuring the following 3 Kanban metrics for one of the development teams I lead. 

Lead Time - from Create Date to Resolution Date

Cycle Time - from the moment issue gets picked up out of "to-do" into "in progress"

Throughput - # of issues closed per month 

Lead time and throughput are easy. I can use fields in Jira. I just create a Jira filter, extract the data I need, pull it into Excel and create easy Pivot tables. 

What I need help with is Cycle Time. Is there any way in Jira that whenever an issue moves from one particular status (To Do) to another (In Progress), that a field is updated like "Date Picked Up"? 

This would be a time saver as I'm doing this  now manually. 

Cheers,

[Zoryana Bohutska _SaaSJet_ · Accepted solution]

Hi @Evelyn Dieppa 

Also, you can try alternative solutions:

- the build-in Jira tool Control Chart

and solution from Atlassian Marketplace like that:

- Time in Status for Jira Cloud - lets create status group for calculation the sum of time spent in statuses

- Time Between Statuses - lets you calculate the Cycle and Lead Time by setting start/stop/pause statuses for status to status time calculation in the configuration menu

Hope it helps

[Evelyn Dieppa]

Thank you Zoryana for your ideas! I will check these out to see if it fits our needs! Appreciate it!

[Emre Toptancı _OBSS_ · Accepted solution]

Hello @Evelyn Dieppa ,

If you are interested in a ready built solution, our team at OBSS built Time in Status app for this exact need. It is available for Jira Server, Cloud and Data Center.

Time in Status allows you to see how much time each issue spent on each status or assigned to each assignee as well as entry/exit dates for all statuses. You can calculate averages and sums of those durations grouped by issue fields you select. (For example see the average InProgress time per project and per issuetype.)

You can also combine statuses into consolidated columns to see metrics like Cycle Time or Lead Time.

The app has custom calendar support so you can get your reports based on a 24/7 calendar or your custom business calendar. (This one is important because a 24/7 calendar in most cases shows misleading data. For example an issue created at 16:00 on Friday and was resolved at 09:00 on next Monday seems to stay open for 2,5 days but in terms of business hours, it is only a few hours. You can see this using Time in Status by OBSS.)

Using Time in Status you can:

• See how much time each issue spent on each status, assignee, user group and also see dates of status transitions.
• Calculate averages and sums of those durations grouped by issue fields you select. (For example see average InProgress time per project and per issuetype.)
• Export your data as XLS, XLSX or CSV.
• Access data via REST API.
• See Time in Status data and charts for each issue as a tab on issue view screen.

https://marketplace.atlassian.com/1211756

EmreT

[Emre Toptancı _OBSS_]

Hello @Evelyn Dieppa ,

We recently prepared a use case document that explains how to calculate throughput using Time in Status by OBSS. You might also want to check it out:

https://dev.obss.com.tr/confluence/pages/viewpage.action?pageId=303795348

EmreT

[Emre Toptancı _OBSS_]

Hello @Evelyn Dieppa ,

We recently prepared a use case document that explains how to calculate throughput using Time in Status by OBSS. You might also want to check it out:

https://dev.obss.com.tr/confluence/pages/viewpage.action?pageId=303795348

EmreT

[Evelyn Dieppa]

Thanks EmreT for all your input /feedback and your recommendation of the ready built solution. 

[Antuan Sammak]

.

[Bill Sheboy]

Hi @Evelyn Dieppa 

In my view, there are several answers to this question, subject to your desire to spend money, do work implementing, and do work maintaining.  Any of these methods need the team to update JIRA consistently.

1. Manually track the work as it moves in JIRA, and record it somewhere outside of JIRA.  This is a pain and error prone.  But, you will get exactly what you want.
2. Buy an add-on which has access to the logs, and can roll-up the data.  This can be expensive (monthly charges) and easy to use, but... many of these solutions appear to scan the logs each time you want the information.
3. You could use either a webhook or the REST API to push (or pull) the data out of JIRA and parse it.  Each requires a bit of learning and finesse to parse the JSON into something you use. For the REST API, you'd need to regularly pull the data.
4. You can add custom fields and use automation rules to set and measure values. This is easy to set up, and persistent.  And no monthly add-on costs.

This last option is what I just implemented for my team, adding start/end datetimes and cycle time custom fields. I used status changes as triggers, and final resolution to calculate the cycle times, lead time, etc.  The bonus was that once I had the data, I could create an actual CFD, WIP over time, WIP age charts, histograms, etc.

Best regards,

Bill

[Evelyn Dieppa]

Bill your answer was extremely helpful! Thanks for writing such a thoughtful response. I am currently doing #1. We are planning a migration to the Cloud soon and will re-assess options after that has been completed! 

[Teh Kok How]

How do you create the charts? There are only CFD and Control Chart in the "Reports" tab of kanban board.

[Bill Sheboy]

Hi @Teh Kok How 

You have a few options for visualizing the information:

• export to a spreadsheet and build your own charts
• use the Jira Excel or Google Sheets add-ons to pull data and build your own charts
• build a dashboard gadget to display within Jira
• buy (or find a free) marketplace add-on to enhance reporting.  We did this one.

Best regards,

Bill

[Teh Kok How]

Hi @Bill Sheboy can you share which add-on do you use? Thanks.

[Aron Gombas _Midori_]

Shameless plug: Better Excel Exporter can do this.

You should definitely check out the "time in status" report template and customize that if needed.

[Bill Sheboy]

Hi @Teh Kok How 

First thing, I am a consumer, not a vendor recommending a product.  With that out of the way...

We are using Great Gadgets for Jira Cloud.  It is very lightweight, relatively low-cost, predictable/consistent in behavior, and their support is very responsive to issues and suggested improvements.

I like (but have not used) ActionableAgile for Jira - Agile Metrics.  After reading the book the product is based upon, I created all of that reporting in Excel by myself, before I learned of this add-on.  They seem to effectively create it in Jira.

__Bill

[Barbara Dewulf]

@Bill Sheboy 

Can you share how you used the automation? Been trying to find a way to calculate this cycle time but my automation rules don't seem to work.. 

[Barbara Dewulf]

@Bill Sheboy 

Can you share how you used the automation? Been trying to find a way to calculate this cycle time but my automation rules don't seem to work.. 

thank you! 

[Bill Sheboy]

Hi @Barbara Dewulf 

For your rule, please post an image of it and the community will be better able to provide suggestions.

Here's an outline of what we did.  If you want a more detailed explanation, I can add that, per your request.

• First thing: chat with the team about measurement and interest level
• Pause and consider your workflow and what you want to measure
• Map out your workflow, including any possible backward flow transitions
• For each thing you want to measure
  • Add custom fields for StartDateTime, EndDateTime, and TimeInStatus
  • Add automation rules to start/stop the clocks
  • For the "done" rule, calculate your cycle and lead time values
• Once we had these in place we then decided to add an Age of WIP measure with a scheduled rule 

Best regards,

Bill

[Brian Estrada]

Hi @Bill Sheboy, I am new to automation rules and stuff, and wanted to know if you can explain in detail the steps you did

[Bill Sheboy]

Hi @Brian Estrada -- Welcome to the Atlassian Community!

The basic steps ares similar to what I noted above, where custom fields are added for each status/thing you want to track and then use automation rules triggered on issue transitions to set them.  Then add a separate rule to compute the differences for the time tracking.  The tricky part is the details, and changes in Jira behavior...

For example, if you analyze your team's workflow and determine issues can move backwards in flow, you will need to decided how to respond/calculate what you need.  This could be quite complex

And...Jira has a recent "improvement" where the status can now be set when creating an issue.  This effectively doubles the number of rules needed to track cycle time!

We eventually stopped using this approach and purchased a basic addon which could measure/plot cycle time.  If you still want to try this rule-based approach, I recommend building one rule for one status first to learn what is needed, and then decide how you want to proceed.

Kind regards,
Bill