Cycle time

Cycle time measures the time it takes from when development picks up a task to when these code changes are available to the end user. Fast and predictable cycle times are an indication of a development team’s agility. Cycle times provide a measurement of how quickly tasks or defects can be resolved.

Cycle time provides an overview of the health of practices of a team iteratively delivering work.

As an engineering manager, you can use this screen to understand the average time it takes for work to start and complete in your organization, where issues and pull requests represent the team’s work. As you find ways to shorten those cycles, your team can become more effective. The more efficient your team is, the shorter the cycle times with less work in progress.

The faster your team can complete these smaller chunks of work in a consistent way, the more predictable and the faster the team can react to changes and feedback, which in turn accelerates the value that is delivered over time.

Using this screen, you can:

  • Evaluate how quickly your team is getting work done (how long it takes work to complete once it is started).

  • Evaluate how quickly the teams is able to turn around user stories, defects, or other defined issues types or work categories.

  • Filter the noise out of the work, so work is more closely aligned with value.

Insights gained

Well-functioning teams try to move towards low cycle times. High cycle times can be caused by:

  • Poorly scoped work, such as monolithic projects that are not chunked into smaller deliverables and iterations.

  • Poorly understood work requirements.

  • Context switching, where you are switching between too many tasks instead of a single task.

  • Too many distractions prevent team members from completing their work.

  • Changing priorities leaving abandoned projects.

  • Not enough people working together towards a common goal; each person does their own siloed work instead of collaborating.

  • Long review cycles.

  • Long intervals between when code is committed and when it’s delivered (delivery cycles).

  • Lack of automation, slow or unreliable test, build, deploy automation.

  • Unnecessary or inefficiently managed queues in the process, like hand-offs, approvals, etc.

Improving the cycle time helps you scope availability to take on additional work and plan when work can be delivered.

Requirements

To view data on Cycle time, a CloudBees Engineering Efficiency admin needs to connect an issue tracker and source control management tool. This will show you the cycle time for issues from when they were moved to in progress to when they were marked as done, with a breakdown into major phases of development process from first commit, to when the pull request was opened, to when it was merged. In addition, you can view deployment times by connecting a CI/CD tool like CloudBees CI.

Configuring connections for Cycle time requires CloudBees SDM administrator rights.

The following minimum requirements are needed to provide basic visualizations:

Additional integrations to view deployment times

To also see deployment times, a CloudBees Engineering Efficiency admin needs to:

  • Configure at least one Jenkins integration.

  • Link Jenkins jobs to the product.

  • Issue tracker configured with an issue state that contains "review."

Deployment jobs need to be triggered directly from a code merge in order to calculate the time from merge to deployment. If this is not possible, deployment time will only take the set of jobs into account that triggers from the merge. Refer to the Configuring deploy cycle times section for more information.

To get a break down of the issues cycle time between in-progress duration and in-review duration, your issue tracker needs to have an issue state that contains "review". If this state is present, we automatically infer the in review time for your issues. The dark purple review bar only shows up if you have defined a review process in your issue tracker.

UI elements

Cycle time has five main UI elements.

cycle time ui elements
Figure 1. Cycle time UI elements
Table 1. Cycle time UI elements
Number Element Use

1

Filters the data displayed by time intervals, Jira projects, or issue type or work category.

2

Check box to show only issues that have associated pull requests.

Reduces the displayed data set to show only issues that have pull requests. Requires a GitHub integration.

3

Provides the average cycle time for the selected time range.

4

Provides a summary of the cycle time for issues in progress.

5

The displayed intervals match the chosen time interval; default value is 7 days. If no data is available, then the bar graph for those time intervals is not displayed.

Understanding the data

Cycle time measures the time it takes from when development picks up a task to when these code changes are available to the end user. Cycle time describes the duration from when an issue was moved to in-progress to when it was marked as completed in the issue tracker. The calculation uses only resolved issues; subtasks are not included.

What does it mean if a percentage of closed issues have no cycle times? This can happen when an issue that hasn’t started—​changed to an in-progress state—​moves directly to a completed, or "Done", status. This typically happens when tickets are closed with a resolution of "Won’t do" or when no-longer-valid issues are cleaned up. An issue can have no cycle time when a developer forgets to change an issue to in-progress and later closes it as a done issue.

How development process impacts cycle time

CloudBees Engineering Efficiency module breaks down cycle time for issues into the code changes and pull requests to see how these are contributing to the overall cycle time. It does this by looking at which pull requests are associated with the issues. The issues represent work that the team is picking up and how much work is getting done through your pipeline on a regular basis. The more that work is closely aligned to value, the more that this represents how often value is delivered by the team. This gets broken down into major phases, depicted in the two bars.

cycle time purple grey bars
Figure 2. Phases of work and how long they take

The purple bar represents the impact of the issues on in-progress and in-review time. The light purple color represents the average length of time from when an issue was first moved to an in-progress state to when an issue changed to an in-review state. The second half of the bar, in dark purple, shows the average length of time an issue was in review to when it was closed.

Selecting any of the color segments shows a summary of the topic and quartiles, for example, which issues impact in-progress time the most, with the quartiles showing the fastest to the slowest times.

The grey and blue bar represents local development time from the time the work is first started to when the first commit occurs. The first commit is noted by an arrow (number 1 in the screenshot below). The light blue section represents when the first pull request is opened.

These averages provide some predictability about the work cycle of your team. These metrics can be interdependent. For example, if you choose to increase the visibility of a pull request through early commits, while your team has more opportunities for code changes it also means that the time from pull request opened to pull request merged increases. Some teams focus on visibility by opening PRs early perhaps at the cost of keeping pull requests open longer.

cycle time bars
Figure 3. Interpreting the grey and blue bar
Table 2. Parts of the grey and blue bar
Marker What it shows How it is calculated Why it is important Actions to take

1 - First commit

Length of time from after an issue is started to when the first commit happens.

Average time for all merged pull requests in the selected time frame from when the associated issues were moved to in progress the first time to when the initial commit happened.

It hints at the relative effort/lag between starting a ticket and initial code being committed.

These actions are general because how you help improve the first commit time depends upon how your team works.

2 - Time from first commit to pull request opened

Which pull requests were worked on the longest.

Average time for all merged pull requests in the selected time frame from when the first commit happened to when the pull request was opened.

Provides an insight into the team’s local development work patterns.

To increase visibility, you can encourage the team to push commits as draft (WIP) pull requests. This helps the team have awareness of impending code changes and provide early code reviews.

3 - Time from pull request opened to pull request merged

Which pull requests take the longest time to merge.

Average time for all merged pull requests in the selected time frame from when the pull request was opened to when the pull request was merged.

Shorter cycle times tend to have shorter, faster reviews and less code churn.

To shorten cycle times, encourage the team to focus on completing reviews in a timely manner.

4 - Time from pull request merged to deployed (requires CI/CD data linked to a product with an active CI/CD integration).

How long does it take for merged changes to be deployed.

Average time for all merged pull requests in the selected time frame from when they were merged to when the deployment job was finished.

One best practice is to have a short time between when code is merged and then deployed to production.

Automate the process of pushing code changes to production, preferably run on every code change. Shorten the times by running that automation, such as on every code change.

Only merged pull requests are taken into account for these calculations. Closed and open pull requests are ignored.

Deploy cycle times only appear under specific conditions, detailed in the Configuring deploy cycle times section.

Understanding distribution and deviation from average

While averages provide a good approximation, they don’t account for outliers or deviations and don’t show the full picture of what issues or pull requests had most or least positive impact on cycle time.

To understand what issues or pull requests contributed most to the cycle time, click on one of the phases for either issues or pull requests and you will see a breakdown into quartiles grouping the issues and pull requests from fastest to slowest.

Table 3. Quartiles
Label Quartile What it shows

Fastest

1st quartile; top 25%

The fastest 25%. For example, The set of issues that were in the top 25% of shortest times for that section.

Faster

2nd quarter; mid-upper 25%

The second fastest 25%.

Slower

3rd quartile; mid-lower 25%

The third fastest 25%.

Slowest

4th quartile; lowest 25%

The slowest 25%.

One way to improve your cycle time is to chip away at the slowest contributors of cycle time. The more you can speed up the slowest contributors, you can improve the overall cycle time.

Viewing data summary and issues list

Each color segment is interactive: you can select a color segment for a data summary or select a quartile to drill-in for an issue list.

To view a data summary for a color segment, select the color to view a tooltip with a data summary of the quartile results from fastest to slowest.

To view a list of issues associated with a quartile:

  1. Select a quartile to display a list of associated issues.

  2. (Optional) Sort any of the columns by selecting them to toggle between ascending and descending order.

If an issue list contains more than 100 items, additional results appear on subsequent pages and can be viewed using the page navigation at the bottom of the screen.

Configuring deploy cycle times

Deployment jobs are configured using Manage jobs and require an active CI/CD integration. You can identify individual jobs as deployment jobs by using the slider.

Refer to the Deployment jobs section for instructions on how to identify deployment jobs.

For deployment jobs to contribute properly to cycle time calculations, the merge commit needs to appear directly in the build result from a deployment job. If this is the case, then the time between merge and build end is counted as deployment time.

Deployment time is not currently supported for cases where a Jenkins job builds the merge commit and produces an artifact that is used by a downstream deployment job.

How are pull requests associated with issues?

To see the breakdown of cycle time into the development process, you need to understand which code changes (pull requests) are associated with which tickets. The association is established by adding the issue/ticket ID to the pull request titles in your source code management system.

You can filter issue cycle time just by issues that had merged pull requests associated, which gives you a more accurate picture of development process, removing any issues that didn’t require changes to code, such as design tasks.

Viewing changes over time with the trend chart

This chart demonstrates how cycle time changes over time. The individual data points on the trend chart represent what the cycle time would have been if all open issues were closed at that time.

The drops, where the line declines at a sharp angle, shows when issues were closed and they were no longer part of the calculation. Cycle time duration is lowered by reducing debt.

cycle time histogram
Figure 4. Cycle time trend chart

Filter cycle time by multiple dimension to get more concrete data

For cycle time to become more actionable, it is important to be able to slice and dice the data and look at it from different dimensions. How do different teams perform? Is cycle time different for different components? Are we resolving bugs faster than stories? How small are we able to break down iterations / user stories? What is our defect resolution time?

That said, the content the team is moving through the development process matters, it matters where it comes from and it matters how it is treated and processed. Not all content has the same criticality and can be assessed in the same way. Thus, CloudBees Engineering Efficiency allows to break down and filter cycle time by multiple dimension:

Changing views by filtering

You can modify the data that is displayed and how it is filtered.

Data filters
Figure 5. Cycle time data filters
Table 4. Cycle time data filters
Number Filter What it shows

1

Time range

Lets you change the view from a week to a year.

2

Jira projects

Lets you filter data from all or selected projects.

3

Work categories

Lets you filter data by Work categories you define.

4

Issue types

Filters data by standard issue types, such as bug, story, or task.

Changing the timeframe using time ranges

You can customize the time period each bar represents.

The Time range drop-down provides three range options, representing a week, a month, 3 months (a quarter), and a year. The default time interval is 7 days.

To change the time intervals on Cycle times:

  1. Select the drop-down under Time range.

  2. Select an option: 7 days, 30 days, 90 days, or 365 days.

Associating and filtering by Jira projects

By default, Cycle time displays data from all Jira projects associated with a product. You can choose which Jira projects to include by selecting individual projects from the Jira projects drop-down.

To filter by Jira projects on Cycle time:

  1. Select the drop-down under Jira projects.

  2. Select the check box next to the Jira projects you wish to display.

You can associate additional projects from Manage Jira projects.

Filtering with Work categories

You can focus the cycle time view to specific work categories. Work categories must be created and associated with products. For example, you may have Jira labels that match specific types of work, such as design, documentation, or security. You can associate one or more labels with a work category and associate those categories with one or more products.

For more information, refer to Work categories.

Issues inherit the work category labeling through the epics.

To change the view using work categories on Cycle time:

  1. Select the Work categories drop-down.

  2. Select the check box next to one or more categories.

Filtering with Issue types

Issue types, defined in your Jira Cloud or Server instance, can include story, bug, task, and other user-defined types within projects or across organizations. By default, all issue types are selected for cycle time calculations. When you select specific issue types from the Issue types drop-down, these calculations are updated based upon the data related to these issue types for linked projects. Issue types are directly imported into the System of Record when Jira is configured.

To filter by issue types on Cycle time:

  1. Select the drop-down under Issue types.

  2. Select the check box next to one or more issue types.

Next steps