Does cycle time carry over sprint to sprint

Question

My team uses the Control Chart in Jira to track our velocity and obtain metrics for our estimation process.  When looking at an issues cycle time, if it was worked on in multiple sprints, does the cycle time show for all sprints?  I use the date selection to only look at work from a given sprint but it seems like cycle time could be additive from earlier work.

Emre Toptancı [OBSS] · Answer

Hello @Michael Walker ,

Control Chart works by showing the overall duration for a subset of columns and if your issue was reopened during its lifetime, Control Chart will show the total duration. Here is a quote from Control Chart documentation that points to this:

Cycle time is the time spent working on an issue — typically, the time taken from when work begins on an issue to when work is completed, but it also includes any other time spent working on the issue. For example, if an issue is reopened, worked on, and completed again, then the time for this extra work is added to the cycle time.

The timeframe selection in Control Chart seems to be affecting only which issues to include in the report but apperantly does not allow you to see only a segment of issue histories.

As an alternative, if you are interested in a ready built solution, our team at OBSS built Timepiece - Time in Status for Jira app for this 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 or group. You can combine statuses into consolidated columns to see metrics like Age, Cycle Time or Lead Time. All durations can be display in various formats including days, hours, minutes even seconds.

The important feature for your case is History Trimming. Time in Status allows you to set a date range for the report and only parts of issue histories that are between the given dates are included in the report. If you set those dates to your new sprint, the report will simply ignore what happened earlier.

The app 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 OR see the sum of InProgress time per component).

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. Get metrics like Lead Time or Cycle Time.
* 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.

Timepiece - Time in Status for Jira

EmreT

Bill Sheboy · Answer

Hi @Michael Walker

Based upon the documentation for the "control chart" report, it would include the date range and status values you select.  To include items which you want to measure that span sprints, you would include the relevant data ranges.

https://support.atlassian.com/jira-software-cloud/docs/view-and-understand-the-control-chart/

Of note, there are some use cases described in that documentation that might give you ideas for quick filters to reduce the noise on the chart, helping you see just velocity (done work) versus other in-progress cycle times.

Best regards,

Bill