Idle Time Metric
Companies use this Cycle Time insight to measure the time it takes for reviewers to pick up pull requests and start reviewing them. By keeping the idle time to a minimum software development teams streamline the review process by avoiding context switching due to pull requests going cold. Become an elite performer by reducing development lag and maximizing the fluidity of your processes.
Reduce Review Lag
with the
Idle Time Metric
Companies use this Cycle Time insight to measure the time it takes for reviewers to pick up pull requests and start reviewing them. By keeping the idle time to a minimum software development teams streamline the review process by avoiding context switching due to pull requests going cold. Become an elite performer by reducing development lag and maximizing the fluidity of your processes.
![Idle Time Metric](https://cdn.prod.website-files.com/625540b970bc1b4035617258/666ab962d0b2ec545a32897c_idle-time.webp)
From startups to large enterprises, Keypup serves all the unique complexities related to project size, structure and teams, including:
What is the Idle Time Metric?
The Idle Time metric calculates the average duration between the moment a review was requested on a pull request to the moment it was picked up by a reviewer (creation of the review). Engineering teams must reduce the review lag to streamline the overall delivery process and avoid context switching due to outdated PRs
Strategies to Reduce the Idle Time
Reduce the size of development items
This will streamline the review tasks. Bigger pull requests are less likely to be picked up for review and are more difficult to test and deploy.
Locate bottlenecks in engineers’ planning
Use the Value Stream Management dashboard to understand your engineering habits and patterns or check the Sprint overview dashboard to assess your engineering team’s planning and activity.
Prioritize the review process
Give dedicated time to engineers to review the work of others. E.g. make mornings a time during which everyone focuses on reviews. Take review time into account in the sprint estimation to ensure developers are not pressured to "develop first, review later".
Change your team culture to adopt a quality-first approach, instead of monitoring quantity as the only metric.
Train junior and mid-level engineers to do reviews
Relying on senior engineers to do all the review work quickly leads to bottlenecks in the review process. Instead, get senior engineers to teach more junior engineers how to do efficient reviews. Assign engineers to peer reviews based on the complexity of the pull request and their level of seniority.
By having more people involved in the review process your idle time will gradually decrease.