Refactor Metric

Definition

Refactor measures the percentage of code changes in merged Pull Requests (PRs) that modify existing code (as opposed to adding new code or deleting code).

It reflects effort spent improving or restructuring existing code.

In LinearB, legacy code is defined as code that has not been modified in the past 25 days.

Only merged PRs are included in this metric.

How Refactor Is Calculated

Refactor is calculated using the following formula: (Lines modified that are ≥25 days old ÷ Total lines changed) × 100

• Code ≥ 25 days old → counted as Refactor
• Code < 25 days old → counted as Rework

Where:

• Lines modified = changes to existing lines of code
• Total lines changed = lines added + lines modified + lines deleted

The headline value represents:

Total lines modified that are ≥25 days old ÷ Total lines changed across all merged PRs in the selected time range

This is a weighted percentage, calculated across the entire selected time range — not an average of daily values. 

How the Metric Is Displayed in the Dashboard

The metric card displays two types of values:

1. Headline Value (e.g., 8.21%)

The large percentage at the top represents the aggregated Refactor percentage across the selected time range.

It reflects the proportion of modified lines relative to total code changes for all merged PRs during that period.

2. Time-Based Values in the Chart

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

Each point represents: Total lines modified ÷ Total lines changed within that specific time bucket

Clicking a point displays:

• The Refactor percentage for that date
• The total number of code changes analyzed

Daily values are calculated independently per bucket and do not average to produce the headline value.

Why This Metric Is Useful

Refactor provides visibility into:

• How much development effort is spent improving existing code
• Whether technical debt is being actively addressed
• The balance between feature delivery and codebase maintenance

Sustained refactoring can improve:

• Maintainability
• Readability
• Long-term stability

However, excessive refactoring during high-delivery periods may indicate:

• Unplanned clean-up work
• Hidden stability issues
• Misaligned sprint priorities

How to Interpret Refactor

Refactor should be interpreted in context.

Consider:

• The stage of the product lifecycle
• Release pressure
• Ongoing architectural changes
• Team maturity

As general guidance:

• 20–40% of changes spent on refactoring is often considered healthy.
• Extremely low Refactor may signal accumulating technical debt.
• Extremely high Refactor may delay feature delivery.

Refactor should be evaluated alongside:

• New Work
• Rework
• Cycle Time

Data Sources

Refactor is derived from:

• Repository diff data
• Code modification patterns

Tunable Configurations

Refactor behavior may depend on:

• The definition of “legacy code” (e.g., 25-day threshold)
• Repository inclusion and filtering rules
• How modified lines are classified

Limitations

• Refactor measures code modification volume, not impact.
• It does not distinguish between minor edits and architectural improvements.
• It does not evaluate whether refactoring was necessary or strategic.
• Formatting-only changes can inflate results.
• Small datasets may produce volatile percentages.

Refactor reflects change distribution, not code quality.

Stakeholder Use Cases

Engineering Managers

• Monitor balance between feature work and technical debt reduction
• Detect over-refactoring during high-delivery periods

Developers

• Justify time spent improving code quality
• Track long-term codebase health

Product Leaders

• Understand delivery trade-offs during roadmap planning