Hi all,
I've been trying to figure out a couple of things. Firstly, how can I calculate the difference between the values of "Lead Time Start" and "Lead Time Stop"? I have two automation rules set up, one for setting the former value, and another to calculate the latter (the Lead Time Stop will display the actual lead time).
The "Lead Time Stop" automation rule has the following issue field edit smart value:
{{triggerIssue.updated.diff(issue.properties.leadTimeStart)}}
However, it does not display a value. Is my syntax wrong?
My second question is related to displaying the dates in a different format. I have tried using, for example, {{now.jqlTime}}, however the date displayed in the "Lead Time Start" field in the task shows up as "Aug 04, 2023" no matter what I try.
Would appreciate help with this! Thanks:)
Hello @de Angelis, Nicholas
I see that you are trying to measure Lead Time with Automation. It is of course doable but there are several downsides to this approach. You will need to build and maintain this solution yourself (which is really expensive). You will need to build this for all different times you want to measure. Finally, it will not work for past issues (even though the needed data is available in each issue's history.)
I suggest you use a marketplace app for this.
I can recommend Timepiece - Time in Status for Jira which is built by my team at OBSS. 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 and on each assignee.
Time in Status offers two report types for your case:
The first one is Status Duration report (please see the screenshot above) which shows how much time each issue spent on each status. You can combine status times to see measurements like Issue Age, Cycle Time, Lead Time, Resolution Time etc.
As an alternative approach, Time in Status also has Duration Between Statuses report type which shows the duration between two specific statuses. This report type also allows the user the exclude the times for "pause" statuses.
These reports show a list of issues by default so you can see the metric values for each issue separately. Also, for all numeric report types, you can calculate averages and sums of those durations grouped by the issue fields you select. For example lead cycle time per customer (organization) 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.
All these report types, including averages and sums, can be turned into charts.
Time in Status 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.
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.
And the app has a REST API so you can get the reports from Jira UI or via REST.
Timepiece - Time in Status for Jira
EmreT
Hi @de Angelis, Nicholas 👋
As an alternative , I guess you can try Time in Status for Jira Cloud (developed by my team). The primary purpose is to help teams gather valuable data about the lifecycle of your issues in Jira. Add-on allows you to measure and visualize Lead and Cycle time to help you identify areas for improvement.
For this you should create only status group and you will get Lead or Cycle time report in your dashboard.
Also Time Between Statuses will be an option for you too. This add-on, which measures connections in the workflow, through a transition time in specific issues. You can count Cycle and Lead Time by setting start/stop and pause statuses in the configuration manager. To detail the calculation conditions you should select the first/last transition to/from status. This add-on also developed by my team.
Add-ons have a 30-day free trial version and free up to 10 users.
Please, let me know if you have any questions
Hope it helps 😌
Valeriia
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @de Angelis, Nicholas -- Welcome to the Atlassian Community!
Your syntax to access the property is correct. And, I believe entity properties are stored as JSON blobs, so effectively as text for what you are doing. Please try converting with .toDate before using the value. I believe this will answer your second question also: convert to a date before trying to format the property value.
Next, what do you mean by "lead time"? A typical definition is "calendar time from request to deliver", and so that could be from when the issue is created until it is resolved. This would eliminate the need for the property.
Are you instead measuring something like build cycle time: working hours time from start of work until completed? If so, how are you accounting for the non-working hours, daily? I have seen this done with more complicated rules...or with marketplace addons.
Kind regards,
Bill
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.