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.
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.
To view data on Cycle time, a CloudBees Engineering Efficiency admin needs to connect an issue tracker and source control management tool. This shows you the cycle time for issues from when they are moved to an in-progress status to when they are marked as done, with a breakdown into major phases of development process from first commit, to when the pull request was opened, and 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:
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 status 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 status that contains "review". If this status is present, we automatically infer the in-review time for your issues. The dark purple review bar is presently only if you have defined a review process in your issue tracker.
Cycle time has five main UI elements.
Filters the data displayed by time intervals, Jira projects, or issue type or work category.
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.
Provides the average cycle time for the selected time range.
Provides a summary of the cycle time for in-progress issues.
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.
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. The calculation also ignores issues with "Won’t Fix," "Won’t Do," "Invalid," "Canceled," "Declined," or "Duplicate" statuses.
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 status—moves directly to a completed, or "Done," status. This typically happens when issues 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.
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.
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 status to when an issue changed to an in-review status. 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.
|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 an in-progress status the first time to when the initial commit happened.
It hints at the relative effort/lag between starting an issue 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.
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.
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.
|Label||Quartile||What it shows|
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.
2nd quarter; mid-upper 25%
The second fastest 25%.
3rd quartile; mid-lower 25%
The third fastest 25%.
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.
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:
Select a quartile to display a list of associated issues.
(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.|
|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.
To see the breakdown of cycle time into the development process, you need to understand which code changes (pull requests) are associated with which issues. The association is established by adding the issue 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.
In this example, the far right purple bar (2) matches the horizontal purple bar (1) in the section What are the phases of work and how long do they take?. The dark purple represents in-review issues and light purple in-progress issues.
The time represented by each bar matches the selected time range with the entire graph showing six months of cycle time history. In this example, the selected time range is one week. Each bar represents one week of time, with the bar on the far right representing the most recent.
For cycle time to become more actionable, it is important to look at the data from a variety of 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?
The work 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:
You can modify the data that is displayed and how it is filtered.
|Number||Filter||What it shows|
Lets you change the view from a week to a year.
Lets you filter data from all or selected projects.
Lets you filter data by Work categories you define.
Filters data by standard issue types, such as bug, story, or task.
Exclude issues without linked pull requests
Removes any issues that do not have associated pull requests.
You can customize the time period each bar represents.
The Time range drop-down provides three range options, representing 7 days, 30 days, and 90 days. The default time interval is 7 days.
To change the time intervals on Cycle times:
Select the drop-down under Time range.
Select an option: 7 days, 30 days, or 90 days.
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:
Select the drop-down under Jira projects.
Select the check box next to the Jira projects you wish to display.
You can associate additional projects from Manage Jira projects.
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.
You can use the + Create new work category to add a new work category and Manage work categories to view a list, add, and remove work categories. 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:
Select the Work categories drop-down.
Select the check box next to one or more work categories.
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:
Select the drop-down under Issue types.
Select the check box next to one or more issue types.