PR Size (p75)

Overview

PR Size (p75) measures the 75th percentile of pull request sizes across your team or organization. This metric helps you understand typical PR size patterns and optimize your code review process for better collaboration and quality.

What It Measures

PR Size (p75) shows the size threshold where 75% of pull requests are at or below that value, and 25% are larger. This metric provides a more reliable picture of your team's PR size patterns than averages, as it's less affected by occasional extremely large PRs.

Example: If your team's PR Size (p75) is 300 lines:

• 75% of your PRs are 300 lines or smaller

• 25% of your PRs exceed 300 lines

• This represents your "typical large PR" rather than worst-case scenarios

Where to Find This Metric

Go to Productivity>Velocity>Delivery

• Team Performance Reports: Compare teams and track trends over time

• Individual Analytics: Personal PR size patterns and comparisons to team

• Targets: Monitor and alert on PR size thresholds

• Custom Dashboards: Include in tailored reports and visualizations

How It's Calculated

Size Definition

PR Size is measured as total lines of code changed, including:

PR Size = Lines Added + Lines Deleted + Lines Modified

Important: Only meaningful code changes are counted. Span automatically excludes:

• Generated files (e.g., package locks, build outputs)

• Dependencies and vendor code

• Files matching your configured ignore patterns (using gitignore syntax)

• Non-developer activity (bots, automated commits)

Percentile Calculation

1. Collect all merged PR sizes for the selected entity (person, team, org) and time period

2. Sort PRs from smallest to largest

3. Find the value at the 75th percentile position

Note: Only merged PRs from developer contributors are included. Draft, closed, or abandoned PRs don't affect this metric.

Interpreting the Results

What Different Values Mean

Interpreting Your Results

High P75 Values May Indicate

Process Patterns:

• Feature-complete development style (entire features in one PR)

• Infrequent commit and merge cadence

• Batch-style development workflows

• Long-running feature branches

Potential Challenges:

• Increased review burden on teammates

• Longer PR cycle times

• Higher cognitive load for reviewers

• Increased risk of defects slipping through

• More difficult to provide quality feedback

Low P75 Values May Indicate

Process Patterns:

• Incremental development approach

• Frequent integration and merging

• Well-scoped, focused changes

• Strong trunk-based development practices

Benefits:

• Faster, more effective code reviews

• Lower cycle times

• Easier to understand and test changes

• Reduced review friction

• Better collaboration

Recommended Thresholds

Default Working Norm

Span's recommended threshold for PR Size (p75) is 1,000 lines of code.

This default suggests that keeping your 75th percentile at or below 1,000 lines represents healthy engineering practices. However, optimal thresholds vary based on:

• Programming language: Some languages are more verbose than others

• Architecture style: Monorepos may have different patterns than microservices

• Team maturity: Established teams may optimize for smaller PRs over time

• Project type: Infrastructure vs. application code may differ

Related Metrics

Understanding PR Size (p75) alongside other metrics provides deeper insights:

Other Size Metrics

• PR Size (p50/median): Shows the "typical" PR size (50th percentile)

• PR Size (p90): Captures very large outlier PRs

• PR Size (average): Mean value, more affected by outliers

• PR Size (max): Largest PR in the period

Review & Quality Metrics

• PR Cycle Time: Larger PRs typically take longer to merge

• Time to Review: First review time correlates with PR size

• PR Review Cycles: Larger PRs often need more iterations

• PR Revert Rate: Larger PRs have higher defect risk

Delivery Metrics

• Total Merged PRs: Volume of work alongside size patterns

• Merge Frequency: How often changes are integrated

Common Use Cases

1. Process Optimization

Monitor P75 over time to validate process improvements:

• After introducing PR size guidelines

• Following developer education on incremental commits

• When implementing trunk-based development

2. Team Comparisons

Compare P75 across teams to:

• Identify teams with different development practices

• Share best practices from teams with optimal sizes

• Understand workflow variations across the organization

3. Individual Coaching

Use P75 at the individual level to:

• Identify developers who might benefit from guidance on PR scoping

• Recognize developers modeling best practices

• Personalize onboarding and mentorship

4. Risk Assessment

Correlate PR Size with quality metrics:

• Do larger PRs correlate with higher revert rates?

• Is there a relationship between size and defects?

• How does size impact cycle time and delivery velocity?

5. Workflow Health

Track P75 as a leading indicator:

• Rising P75 may signal growing scope or time pressure

• Sudden increases warrant investigation into root causes

• Sustained high P75 suggests process intervention needed

Automated Insights

PR Size Outlier Detection

Span automatically identifies when an individual's PR Size (p75) is notably higher than their team's baseline using statistical outlier detection (Median Absolute Deviation).

Requirements:

• Minimum 5 merged PRs per person

• At least 4 teammates for meaningful comparison

When flagged, investigate:

• Is the person working on legitimately larger features?

• Do they need support breaking down work more granularly?

• Are there patterns in which types of changes are large?

Configuration Options

Customizing What Counts

In your Span organization settings, you can configure:

1. Ignore Patterns: Define files to exclude using gitignore syntax

   • Lock files and dependencies

   • Generated code

   • Documentation (if desired)

   • Build artifacts

2. Test File Patterns: Track test code separately from production code

3. Repository Filters: Exclude certain repositories from calculations if needed

Best Practice: Ensure organization-wide consistency in ignore patterns for accurate team comparisons.

Important Considerations

Data Requirements

For reliable P75 calculations:

• Minimum PRs: At least 5 merged PRs per person for individual metrics

• Time Period: Longer periods (30-90 days) provide more stable results than weekly views

• Team Size: Comparisons require at least 4 people for statistical validity

What's NOT Counted

• Draft, closed, or abandoned PRs (only merged PRs)

• Bot or automated commits

• Files matching your ignore patterns

• Non-developer contributor activity

Time Period Sensitivity

Different aggregation windows show different patterns:

• 7-day rolling: Sensitive to recent changes, good for immediate feedback

• 30-day rolling: Balanced view for monthly trends

• 90-day rolling: Smooth long-term patterns, best for strategic initiatives

Taking Action

If Your P75 Is Higher Than Desired

1. Educate on Incremental Development

   • Share benefits of smaller, focused PRs

   • Demonstrate techniques for breaking down work

   • Establish team guidelines for PR scoping

2. Review Workflow Bottlenecks

   • Are long-running branches causing large merges?

   • Is infrequent integration leading to batching?

   • Do developers have concerns about "too many PRs"?

3. Improve Work Decomposition

   • Better story splitting in planning

   • Feature flags for incremental feature delivery

   • Architectural patterns that support modularity

4. Set Team Norms

   • Define target PR size ranges

   • Use Span working norms to monitor adherence

   • Celebrate improvements and model best practices

Best Practices for Healthy PR Sizes

✅ Break down large features into independently mergeable chunks
✅ Use feature flags to ship incomplete features safely
✅ Separate refactoring from functional changes
✅ Extract infrastructure changes into separate PRs
✅ Keep formatting/style changes in dedicated PRs
✅ Leverage git commits to tell a story of incremental progress

Where to Find This Metric

PR Size (p75) is available throughout Span:

• Metrics Dashboard: Delivery category alongside other code review metrics

• Team Performance Reports: Compare teams and track trends over time

• Individual Analytics: Personal PR size patterns and comparisons to team

• Working Norms: Monitor and alert on PR size thresholds

• Custom Dashboards: Include in tailored reports and visualizations