PR Size Metric

Definition

PR Size measures the total number of lines added, modified, or deleted in a Pull Request (PR), after applying organization and repository-level inclusion and exclusion filters.

It reflects the scope of code changes within each PR.

How PR Size Is Calculated

PR Size is calculated as: Sum of lines added + modified + deleted − changes in excluded files

Excluded files are defined in repository or organization settings.

If both exclusion and inclusion rules are configured:

1. Exclusion rules are applied first.
2. From the remaining files, only those matching inclusion rules are considered.

How the Metric Is Displayed in the Dashboard

The PR Size card displays two types of values:

1. Headline Value (e.g., 231 Average Code Changes per PR)

The large number shown at the top represents the average PR Size across the selected time range.

This is the average number of code changes per PR — not a total sum.

If the dropdown is switched to Median, the value represents the median PR size instead of the average.

2. Time-Based Values in the Chart

The line chart shows PR Size aggregated per time bucket (for example, daily).

Each point represents the average (or median) PR size for PRs created or merged during that time bucket.

When you click a point in the chart, you see:

• The PR Size value for that specific date
• The aggregation type (Average or Median)

This helps identify:

• Spikes in unusually large PRs
• Periods of unusually small PRs
• Outliers affecting review efficiency

Why This Metric Is Useful

PR Size directly impacts:

• Review depth
• Review speed
• Risk exposure
• Merge time

Large PRs are more difficult to review thoroughly and increase the likelihood of:

• Missed issues
• Delayed approvals
• Longer feedback cycles

Monitoring PR Size encourages smaller, more focused changes that improve review quality and team velocity.

How to Interpret PR Size

PR Size measures the scope of an individual Pull Request and should not be confused with Code Changes metrics, which reflect total development activity across the codebase.

PR Size should be evaluated in context.

As general guidance:

• PRs should ideally remain under 500 lines for optimal review efficiency.
• Consistently large PRs may slow down review cycles.
• Extremely small PRs may indicate over-fragmentation of work.

Average values may be skewed by outliers.

Median is often more representative of typical PR behavior.

PR Size should be reviewed alongside:

• Time to Review
• Time to Merge
• Review Depth

Inclusion and Exclusion Filters

Rule Precedence

If both exclusion and inclusion filters are configured:

1. Exclusion rules are applied first.
2. From the remaining files, only those matching inclusion rules are considered.

Any file excluded in step 1 will not be analyzed — even if it matches inclusion criteria.

This ensures that explicitly excluded files always take priority.

Exclusion Filters

Exclusion filters allow you to ignore specific file types or paths in PR Size calculations.

Common exclusions include:

• Dependency and lock files (e.g., package-lock.json)
• Build artifacts (dist/, public/assets/)
• Auto-generated files
• Non-code files (.csv, .docx, .log, .tar, etc.)

Excluding these files prevents inflated PR Size values caused by non-engineering changes.

Inclusion Filters

Inclusion filters allow you to limit PR Size analysis to specific file types or paths.

When inclusion filters are set: Only the specified files will be analyzed. All others will be ignored.

Examples of inclusion strategies:

• Limiting analysis to source code directories
• Ignoring documentation or configuration files
• Tracking only critical files such as:
  • requirements.txt
  • package.json

Inclusion filters help teams focus PR Size analysis on meaningful engineering changes.

Data Sources

Derived from:

• Repository diff data
• File-level inclusion and exclusion rules configured at the organization or repository level

Benchmarking Guidance

• PR Size should generally remain below 500 lines for optimal review efficiency.
  Larger PRs are associated with:
  • Reduced review depth
  • Longer review times
  • Increased risk of missed issues
  Median PR Size is often more representative than average in teams with outliers.

Error Margins and Limitations

• Non-code files not properly excluded may inflate PR Size.
• Large binary or auto-generated files can distort results.
• Inclusion/exclusion misconfiguration can under- or over-represent engineering effort.
• PR Size measures volume, not complexity or impact.
  PR Size should be evaluated alongside review and cycle metrics for full context.

Why This Matters

For PR Size, filters are not cosmetic — they materially affect the metric.

Without clearly documenting:

• Rule precedence
• Inclusion behavior
• Configuration impact

customers will:

• Misinterpret inflated PR Size
• Assume incorrect engineering behavior
• Open CS tickets

Stakeholder Use Cases

Engineering Managers

• Monitor review efficiency and detect oversized PR patterns.
• Identify contributors or teams consistently submitting large PRs.
• Balance delivery speed with review quality.
• Reduce merge risk by encouraging smaller, incremental changes.

Team Leads

• Enforce PR size guidelines during sprint execution.
• Detect review bottlenecks caused by large submissions.
• Coach developers on breaking work into smaller, focused PRs.
• Improve predictability of review and merge timelines.

Developers

• Submit smaller, easier-to-review PRs.
• Reduce review friction and feedback cycles.
• Improve collaboration and reviewer engagement.
• Decrease the likelihood of large rework cycles.

Reviewers

• Allocate review effort effectively.
• Prioritize high-risk, large PRs.
• Maintain review depth without review fatigue.

Product and Delivery Leadership

• Understand trade-offs between delivery velocity and review quality.
• Detect periods of rushed, large submissions before releases.
• Align engineering practices with roadmap expectations.