Cycle Time Trend Gadget

[lapacquah.bryant]

Hello,

Checking to see if there is a gadget in Jira Cloud compatible to Cycle Time Trend Gadget from Jira Sever/Data Center.  If not is there a JQL I can use to get the same results in a Dashboard.

Thank you 

[Mehmet A _Bloompeak_ · Accepted solution]

Hi @lapacquah.bryant ,

Unfortunately there is no built-in way of getting Cycle Time in Jira Cloud. JQL does not provide cycle time calculation. You either need a marketplace app or Jira automation.

For more information about cycle time you can check the article below
Cycle Time and Lead Time in Jira

[lapacquah.bryant]

Thank you @Mehmet A _Bloompeak_ any suggestions as to how to write the Jira Automation.  I did not see any actions for cycle time but logging work or log action? 

Is this the only way to get a start and stop time for completing an issue/ticket for JSM project.

[Mehmet A _Bloompeak_]

You should populate 2 custom fields. One for storing the progress start time and one for the storing the cycle time.

1. When issue transitions to "In Progress"(the status that starts the cycle time, in your case it can be "Waiting for Support") status, store the current date time in "progressStarted" custom field.
2. When issue transitions to "Done" status, calculate the difference now-progressStarted and store it "CycleTime" field.

Now all the done issues will have a CycleTime field populated.

[lapacquah.bryant]

After setup of custom fields, then I can create an automation rule, however how do I get a report?

[lapacquah.bryant]

Also how will I tie these custom fields to the request type or status.  We use In progress status, with other projects.  Should I create a unique status for capturing cycle start and stop time?

[Mehmet A _Bloompeak_]

• After setup of custom fields, then I can create an automation rule, however how do I get a report?
  - The only was is to use MS Excel. On the "View all issues" page, you should list the issues(including CycleTime field) to be included your report and export the issues in Excel. Then you can create your report in Excel manually.
• How will I tie these custom fields to the request type or status. We use In progress status, with other projects.
  - You can make your automation to work only for a specific project. There are 2 types of automation rules. Global rules and project rules. If you define your automation under "project rules" then the automation will work only for that specific project.
  

[lapacquah.bryant]

@Mehmet A _Bloompeak_  

Thank you for the update.  We need a report that will tell the user a start and stop time for an issue.  When creating the Automation rule, will this populate in the queue via a column for export purposes?  How will they get this information in a report?

[Mehmet A _Bloompeak_]

Yes, you can add custom field to be displayed in your queue. I am not sure if queues are exportable but you can open the queue in issue navigator as in the below screenshot. In issue navigator you can display the custom field and export the issues into MS Excel

[lapacquah.bryant]

@Mehmet A _Bloompeak_ Thank you for the update whats the purpose of the Automation rule?  Looks like if I add the two custom fields to Request Type/Issue View it has to be manually entered or is the Automation rule calculating this part? 

Please provide details around how to set up Automation rule if its needed.

Thank you again for your assistance.  

[Mehmet A _Bloompeak_]

Hi @lapacquah.bryant ,

Automation rule will calculate the custom fields. The first rule be similar to do below one.

Similarly, you will define the second rule and set the CycleTime field as {{progressStarted.diff(now).seconds}}

[lapacquah.bryant]

Hello @Mehmet A _Bloompeak_ 

My custom fields are different does that matter and I set them up as date time pickers fields.  Please advise on custom field formate. 

Thank you 

[Mehmet A _Bloompeak_]

progressStarted field is "date time picker".

CycleTime field is "number field".

[lapacquah.bryant]

@Mehmet A _Bloompeak_ 

Thank you I created two Automation rules, however had a question for CyceTime rule.  Should this condition be "empty" also similar to progressStarted?  

[Mehmet A _Bloompeak_]

It depends on when you want cycle time to be ended. If an issue has transitioned to Done multiple times(e.g New -> In Progress -> Done -> In Progress -> Done), do you want cycle time to stop in the first transition to Done or in the last transition to Done? If you want it to stop in the first transition use the empty condition.

[lapacquah.bryant]

@Mehmet A _Bloompeak_ 

Thank you again.

Currently I am getting an error in the audit log and its an error on a request type that is not associated or I do not want associated with automation rule for progressStarted rule.  

Thus far no calculation as occurred for either of the automation rules.

I created two different rules was this correct?

I also added both custom fields to the request type/issue view that automation rule is associated with.

Any additional detail would be great thank you.  

[Mehmet A _Bloompeak_]

Yes, you need 2 different rules.

If you only want the automation to be triggered for certain request types, you can add another "IF Request Type is one of" condition.

[lapacquah.bryant]

Hello @Mehmet A _Bloompeak_ 

I have completed what you suggested and thus far no information has populated.

Are there any additional idea's or references I can review.

[lapacquah.bryant]

Hello, @Mehmet A _Bloompeak_ 

Does it have more to do with my smart values or the rule itself. For smart values I used what you suggested and added a condition to only capture a certain request type.

The rule produced an error, however it was for the incorrect request type, which is why I added the condition for the specified request type.

Thank you for the assistance.

[lapacquah.bryant]

Hello,

Update, I fixed Automation rule and now the progressStarted populates a start time:  

However, Cycle time automation rule does not populate any information and the rule is listed as "Success" via Audit log.  

This is what shows in Queue:

Question, is the time listed under progressStarted considered the total Cycle Time?

Thank you for your assistance.  

[lapacquah.bryant]

Update:

I found the issue and also changed the CycleTime to display seconds, instead of minutes.

However I have a few follow up questions.

1.  Is there a way to stop progessstart time once ticket is closed.

2.  progessStart is also pulling in other request types thinking it has to do with the first action which is to move tickets into various status etc.   This appears to be how Automation rules operate based on the Trigger.  

Thank you in advance for your assistance.

[Emre Toptancı _OBSS_]

Hello @lapacquah.bryant ,

The closest you can get with out-of-the-box Jira is the Control Chart (which is available as part of Kanban Board reports). However, Control Chart offers limited details and flexibility. For maximum details and flexibility, I suggest you use a marketplace app (I know you said you can't use an app at this point but perhaps you change your idea in the future or others reading this post might benefit from this answer)

Our team at OBSS built Time in Status exactly for this. It is available for Jira Server, Cloud, and Data Center.  

Time in Status mainly allows you to see how much time each issue spent on each status or each assignee.

   

You can combine the time for multiple statuses to get metrics like Issue Age, Cycle Time, Lead Time, Resolution Time etc. 

For all numeric report types, you can calculate averages and sums of those durations grouped by the issue fields you select. For example total in-progress time per customer or average resolution time per sprint, week, month, issuetype, request type, etc. The ability to group by parts of dates (year, month, week, day, hour) or sprints is particularly useful here since it allows you to compare different time periods or see the trend. 

The app calculates its reports using already existing Jira issue histories so when you install the app, you don't need to add anything to your issue workflows and you can get reports on your past issues as well. It supports both Company-Managed and Team-Managed projects for Jira Cloud.

Time in Status reports can be accessed through its own reporting page, dashboard gadgets, and issue view screen tabs. All these options can provide both calculated data tables and charts.

   

Here is the marketplace page for Time in Status by OBSS:

https://marketplace.atlassian.com/apps/1211756/

EmreT

[lapacquah.bryant]

Thank you @Emre Toptancı _OBSS_ 

[Danut M _StonikByte_]

Hi @lapacquah.bryant,

When it is about measuring the cycle time, lead time or time between any workflow statuses, our Great Gadgets app can be of great help.  

It offers some dashboard gadgets that allow measuring cycle time and display it in different ways.

Cycle Time as Trend Chart - allows you to see the average cycle time for past time intervals and displays the trend  

Cycle Time as Control Chart - see the issues by their cycle time and easily identify the one that took longer than expected 

Cycle Time as Histogram Chart - see how many issues were in each range and how many took longer

Have a look over these articles on our blog to see what you can track with our app and how: 

• An effective dashboard for Service Desk and Customer Support teams in Jira Service Management 

• 10 “must-have” gadgets for any Kanban dashboard in Jira 
• How to track multi-team or scaled-agile projects (such as SAFe®) in Jira with Great Gadgets app 

I hope this helps. If you have any questions, please don't hesitate to contact us at support@stonikbyte.com.

Thank you,

Danut

[lapacquah.bryant]

Thank you for the follow up we cannot use apps at this time.