Practise vocabulary for code review metrics: PR cycle time, review turnaround SLA, comments per PR, merge frequency, and code freeze communication.
0 / 5 completed
1 / 5
An engineering manager says 'Our PR cycle time is 3.2 days.' What does PR cycle time measure?
PR cycle time measures the elapsed time from when a pull request is opened (or the first commit is pushed) to when it is merged. It is a key flow metric indicating review process efficiency.
2 / 5
A team adopts a '24-hour SLA on reviews.' A PR is opened Monday at 10 am. By when must the first review be posted?
A 24-hour SLA means a reviewer must provide initial feedback within 24 hours of the PR being opened. This reduces idle wait time and keeps cycle time low. The SLA covers business hours in many teams.
3 / 5
A team's dashboard shows 'avg 8.4 comments per PR.' A tech lead flags this as a concern. Why might high comments per PR indicate a quality issue?
While some comments reflect healthy review, a high average can indicate PRs are too large to review efficiently, coding standards are not well-defined, or architectural decisions are being re-litigated at review time rather than earlier.
4 / 5
A team announces 'we have a code freeze this sprint.' What does this mean for PRs?
A code freeze halts merging of new feature or non-critical changes, typically before a release. It reduces risk of introducing regressions. Only pre-approved hotfixes or release-blocking fixes are merged during a freeze.
5 / 5
A manager reports 'merge frequency dropped from 12 to 4 merges per engineer per week.' What is the most likely operational cause?
Merge frequency (merges per engineer per time period) reflects how smoothly code flows through review. A drop usually indicates PRs have grown larger, review bottlenecks have appeared, or the team has fewer reviewers available — all of which inflate cycle time.