Code Review in the agile flow
Code review is essential for code quality and knowledge sharing. But when poorly managed, it becomes a bottleneck that stalls sprint delivery.
How much time to dedicate to code review
Rule of thumb: 15-20% of sprint time on code review.
In a two-week sprint with 6 developers (~480 total hours):
- ~72-96 hours on code review
- ~12-16 hours per developer
- ~30-45 min per day per person
This should be baked into your estimates. If a feature is 5 points, those 5 already include review time.
Fast review vs. slow review
Fast review (ideal)
- PR reviewed in < 4 hours
- Specific, actionable comments
- Maximum 2-3 review rounds
- Small PRs (< 400 lines)
Slow review (problematic)
- PR sits unreviewed for 1-2 days
- Vague comments (“looks off”, “don’t like it”)
- 5+ rounds of review
- Giant PRs (1000+ lines)
Impact on sprint flow
A PR stuck in review blocks:
- The author (can’t start the next task)
- The feature (doesn’t reach production)
- The sprint (points aren’t delivered)
Rule: Any open PR older than 4 hours should be flagged at the daily standup.
Agile review best practices
1. Small PRs
“The ideal PR: one feature, one logical change, < 400 lines.”
Small PRs get reviewed faster and with better quality. If you need 1000 lines, break it into chained PRs.
2. Review first, code second
Encourage reviewers to do code review before starting their own coding task for the day. Reviewing is unblocked work — it can be done at any time.
3. Automate the obvious
Linting, formatting, and unit tests should run automatically. Reviewers should focus on:
- Architecture and design
- Readability
- Edge cases
- Security
4. Review checklist
- Is the logic correct?
- Do the tests cover the main scenarios?
- Is there any unnecessary code?
- Are variable and function names clear?
- Are there any obvious vulnerabilities?
- Does the change follow project standards?
5. Pair approval
At least 1 approval required for merge. For sensitive code (payments, auth), require 2 approvals.
Code Review and estimates
In Planning Poker, account for:
- Time to write the code
- Time to write the tests
- Time to review and iterate on the PR
- Time to resolve merge conflicts
If you don’t include review time in your estimate, you’re systematically underestimating.
Review metrics
| Metric | What it indicates | Target |
|---|---|---|
| Average review time | Speed of feedback | < 4 hours |
| Average PR size | Quality of changes | < 400 lines |
| Comments per PR | Review quality | 3-10 |
| Review rounds | Change clarity | 1-2 |
| Bugs in production | Review effectiveness | < 5% |
Conclusion
Code review is an investment in quality and shared knowledge. In an agile flow, it needs to be fast and focused. Large PRs are the biggest enemy — break changes into small, reviewable pieces. Every minute spent on review is a minute saved on a future bug.