Cycle time is a key metric for engineering teams. Borrowed from lean manufacturing, in software it measures how long code takes to move through the development pipeline from the first commit to production.
Why care about cycle time?
Improving cycle time means delivering faster, shipping in small batches, and avoiding stale code. Research like Accelerate links shorter cycle times to higher innovation, competitiveness, and organizational efficiency.
Lower cycle time enables:
- Smaller, safer changes
- Faster feedback from users
- Less risk and overhead
- Timely reviews and merges
In DevStats, we focus on the pull request portion of delivery because it is the stage developers can directly influence.
How DevStats measures PR cycle time
DevStats calculates PR cycle time as the total time a pull request spends across these stages:
- Coding Time from the first commit to PR creation
- Pickup Time from PR creation to the first review
- Review Time from the first review to the last review
- Merge Time from the last review to the first merge
- Deploy Time from the first merge until the PR is merged into the deployment branch
You can view merged and ongoing PRs to understand current performance and expected completion times. Closing old PRs lowers cycle time, while keeping stale PRs open pushes it up.
Use these views to investigate:
- PR Cycle Time dashboardfor weekly aggregates, stage breakdowns, and a Scatter view to spot outliers
- Code Review dashboard to track PR Size, comments, and review depth
- Aging Branches report to see active branches by stage and how long they have been there. Click any circle to open branch details
- Benchmarks in the Snapshot section to compare against industry standards
What is a good cycle time?
Use Benchmarks as a guide:
- Elite under 42 hours
- Strong 42–95 hours
- Fair 96–188 hours
- Needs Focus over 188 hours
Selecting the 85th percentile in PR Cycle Time settings gives a stable, realistic baseline that filters out extreme outliers.
What contributes to cycle time?
Focus on the levers your team controls:
- Work in progress too many open PRs increases context switching and waiting
- Time in progress split work into smaller batches that are easy to review and deploy
- Time in review keep PRs small, assign reviewers promptly, and set clear review expectations
- PR size smaller PRs flow faster and are safer to ship
- Time to merge prioritize approved PRs and keep merge queues short. Invest in automation to reduce handoffs between merge and deploy
Lowering cycle time with DevStats
Start with a clean-upIdentify stale PRs in the Open PRs and Aging Branches views. Close or merge what is still relevant and archive the rest. Use date filters to focus on recent work.Adopt a team agreement
Review PR Cycle Time together and set practical targets:
- Target total cycle time, for example 7–14 days to start
- Limit open PRs per squad
- Define review SLAs, for example review within 24 hours and merge within 2 days
- Keep PRs small by default
Build a feedback loop- Watch the Scatter view to catch outliers early
- Check the Code Review dashboard each week to monitor PR Size and Review Time and spot trends early.
- Check Aging Branches to prioritize branches that have waited the longest
- Compare against Benchmarks to set realistic improvement goals