Table of Contents
Cycle Time Metric
This article explains the Cycle Time Metric, which tracks how long it takes code to go from first commit to production. It highlights key stages like coding, review, and deployment to help teams improve efficiency and collaboration.
Definition
Cycle Time measures the total time required for code to move from the beginning of implementation to production deployment.
Specifically:
Cycle Time = Time from coding start to production deployment
Only pull requests that have completed the full lifecycle — including deployment to production — are included.
Components of Cycle Time
Cycle Time is composed of four sequential phases:
1. Coding Time
Time from:
- First commit in a branch
or - Jira issue moved to In Progress (if Jira-based coding time is enabled)
Until:
- Pull request (PR) creation
If Jira-based coding time is enabled, the coding start timestamp is derived from Jira workflow transitions.
2. Pickup Time
Time from:
- PR creation
Until:
- First review activity begins
Pickup Time reflects review responsiveness and team collaboration efficiency.
See: Reducing Pull Request Pickup Time
3. Review Time
Time from:
- First review activity
Until:
- PR merge
Review Time reflects review cycle efficiency.
4. Deployment Time
Time from:
- PR merge
Until:
- Code is deployed to production
Deployment detection depends on configured production signals and integration settings.
How the Metric Is Calculated
Cycle Time is calculated as:
Production deployment timestamp – Coding start timestamp
Where:
- Coding start = first commit timestamp
or Jira In Progress timestamp (if configured) - Production deployment timestamp = first deployment containing the merged PR
Only PRs that have been deployed to production are included.
For a detailed technical explanation, see:
Cycle Time Calculation in LinearB
Normalization
The headline value is normalized to the selected time bucket.
For example:
- Daily view → Average cycle time of PRs completed that day
- Weekly view → Average cycle time of PRs completed that week
- Monthly view → Average cycle time of PRs completed that month
The headline represents:
Average Cycle Time of PRs that completed the full lifecycle within the selected period
This is an average duration, not cumulative time.
How the Metric Is Displayed in the Dashboard
Headline Value
Displays the average cycle time for completed PRs in the selected time range (e.g., 1d, 9h on average).
Aggregation options (AVG, P50, P75, P90) adjust percentile view.
Time-Based Chart
Each chart point represents:
Average (or selected percentile) cycle time of PRs completed within that specific time bucket
Why This Metric Is Useful
Cycle Time reflects end-to-end delivery speed.
It helps teams:
- Identify bottlenecks across coding, review, or deployment
- Improve responsiveness
- Shorten time-to-value
- Align with DORA delivery performance standards
Reducing Cycle Time typically improves overall delivery agility.
Relationship to Other Metrics
Metric | Measures |
Coding Time | Development effort duration |
Pickup Time | Review responsiveness |
Review Time | Review process duration |
Deployment Time | Release pipeline speed |
Deploy Frequency | Release cadence |
Change Failure Rate | Deployment quality |
Merge Frequency | Integration cadence |
Cycle Time measures the complete delivery journey.
Data Sources
Cycle Time is derived from:
- Git commit metadata
- PR creation and merge timestamps
- Review events
- Deployment logs
- Jira workflow transitions (if enabled)
Tunable Configurations
Cycle Time may be influenced by:
- Jira-based coding start configuration
- Production deployment detection configuration
- Branch inclusion/exclusion rules
- Working day exclusion settings
Excluding non-working days affects calculations.
See: Exclude Non-Working Days from Cycle Time
Benchmarking Guidance
High-performing teams aim to:
- Reduce pickup delays
- Keep review cycles efficient
- Deploy frequently
- Break work into smaller batches
Smaller deployments can help reduce downstream failure risk.
See: Reducing Change Failure Rate Through Smaller Deployments
Limitations
- Requires successful production deployment to compute full cycle time.
- Backfilled deployment data may adjust historical values.
- Long-lived branches can inflate coding time.
- Inaccurate Jira transitions affect coding start accuracy.
- Small sample sizes may cause volatility.
Cycle Time measures delivery duration, not code quality.
Stakeholder Use Cases
Engineering Managers
Monitor end-to-end delivery speed and identify bottlenecks.
Team Leads
Improve review responsiveness and deployment cadence.
DevOps / Platform Teams
Optimize CI/CD pipelines and production release flow.
Product Leadership
Measure time-to-value for delivered work.
Related Articles
How did we do?
Cycle Time Calculation in LinearB
Deploy Frequency Metric
