See what's new on Keypup! 📢
Learn more
Lead Time for Changes - Pull Requests (DORA Metrics)
Connect your Git repository to automatically calculate the time elapsed from open to merge at a pull request level.
Automate Lead Time for Change (LTC) Calculation from Your Git Pull Requests
with the
Lead Time for Changes - Pull Requests (DORA Metrics)
Connect your Git repository to automatically calculate the time elapsed from open to merge at a pull request level.



From startups to large enterprises, Keypup serves all the unique complexities related to project size, structure and teams, including:



Understand the Lead Time for Change Metric Template
The LTC metric template provides the average time it takes for a pull request to be merged over the past twelve months.
What Good Looks Like for Lead Time for Change (LTC)
Elite performers observe an LTC below 1H according to the DORA metrics scale. High performers have an LTC below 1 week, while medium performers can see an LTC of up to 6 months. Low performers reach over 6 months for this metric.
How to Improve Your Lead Time for Change (LTC) Metric
- Ensure issues are relatively consistent in size: This allows for easier comparison between pull requests and improves metric reporting accuracy.
- Make sure issues are properly scoped: Clear instructions about the expected logic, the visuals, and the objectives help engineers design the right solution from the start.
- Provide developers with immediate PR feedback on low-level issues through automated code review tools, such as linters and code analysis tools. This will decrease the reliance on senior reviewers for small issues and increase their willingness to complete reviews in a timely manner.
- Peer review bottlenecks are typically caused by senior and mid-level developers being overburdened. If you feel this will help unlock bottlenecks, give your senior staff more time to review pull requests or hire more senior-level personnel.
- Allow your developers to work with your product team while they're developing, not just when the pull request is ready for review. This will prevent back-and-forth development.