Post PR Review Dev Day Ratio (PRR)
Post PR Review Dev Day Ratio (PRR) measures the proportion of coding time that occurs after a pull request review has been completed. It reveals how much rework developers need to perform following code review feedback and helps assess code quality, requirements clarity, and the effectiveness of the review process.
Calculation
PRR is typically reported on a weekly or sprint basis using development activity tied to pull requests. It measures how much coding effort occurs after review versus the total effort spent on a pull request.
The metric is calculated as:
PRR = total development days after PR review ÷ total development days associated with PRs × 100
Goals
PRR helps teams understand code quality and review effectiveness. It answers questions like:
- Are developers submitting pull requests that require substantial rework after review?
- Do developers have clear requirements and expectations before starting development?
- Is the code review process catching issues effectively without being too lenient?
A higher PRR indicates that developers are struggling with code quality or requirements clarity, requiring significant rework after review feedback. This may signal that product managers and tech leads need to set clearer expectations, or that developers need additional guidance or skill development.
However, an extremely low PRR can also be problematic, potentially indicating weak code review processes, rubber-stamp approvals, or insufficient review rigor that allows low-quality code to merge unchecked.
Variations
Common breakdowns of PRR include:
- By engineer, to identify individual developers who may need additional support or clearer guidance
- By team or service, to assess whether requirements and expectations are consistently communicated
- By review complexity, to understand how thorough reviews impact post-review rework
- By PR size, to explore whether larger changes correlate with more extensive post-review modifications
Some teams pair PRR with Review Latency to distinguish between rework due to quality issues versus delays in the review process.
Limitations
PRR captures where development time occurs relative to review, but doesn't distinguish between necessary improvements and unnecessary rework. It also assumes that developer time is properly attributed to pull requests and that reviews are marked consistently in workflow tools.
Both extremely high and extremely low PRR values warrant investigation, as they may indicate different types of process problems.
To provide better insight, pair PRR with:
| Complementary Metric | Why It's Relevant |
|---|---|
| Review Latency | Helps distinguish between rework due to quality issues vs. review process delays |
| Pull Request Size | Reveals whether larger changes lead to more extensive post-review modifications |
| Flow Efficiency | Shows how much of the delivery process is spent actively working versus waiting |
Optimization
Improving PRR involves enhancing code quality, clarifying requirements, and ensuring meaningful but efficient code reviews.
- Establish clear Code Review Standards. Consistent expectations help developers understand quality requirements before submitting code for review.
- Improve requirements clarity. Ensure developers have clear specifications and acceptance criteria before beginning development work.
- Provide targeted coaching. When individual developers show high PRR, investigate whether they need clearer guidance, additional training, or better understanding of requirements.
- Strengthen review processes. If PRR is too low across the team, ensure reviews are thorough enough to catch quality issues rather than rubber-stamping approvals.
- Keep PRs small and focused. Smaller changes are easier to get right initially and require less extensive rework after review.
- Use automated quality checks. Implement linting, static analysis, and CI checks to catch common issues before human review.
- Monitor review thoroughness. Track whether reviews are providing meaningful feedback or simply approving without adequate scrutiny.
PRR helps quantify the relationship between initial code quality and review effectiveness. When developers submit well-prepared code that meets clear requirements, and reviews provide constructive but not excessive feedback, teams achieve optimal PRR ranges that support both quality and productivity.
