Rework Metric

Definition

Rework measures the percentage of classified code changes that revise or remove code introduced less than 21 days earlier.

It represents effort spent revising recently introduced code. LinearB determines Rework from Git commit history, repository diffs, line history, and the classification rules described below.

Rework is calculated from qualifying commit-level changes across all included branches within the selected time range. A pull request’s status does not determine whether its commits are included.

How Code Changes Are Classified

Before calculating Rework, LinearB analyzes qualifying files and classifies code changes as New Work, Rework, or Refactor.

1. Apply file filters. Files that match configured exclusion rules are removed before classification. Depending on the applicable configuration, this may include generated files, lock files, documentation, binary formats, or specified file extensions and paths.
2. Compare deleted and inserted lines within each change block. LinearB pairs deleted and inserted lines within a Git diff block to understand whether existing code was meaningfully changed.
3. Ignore near-identical line pairs. When a paired deletion and insertion are at least 90% similar, LinearB treats the pair as a minor or effectively identical change and excludes both lines from the Work Breakdown calculation.
4. Check the source and age of the remaining changed lines. LinearB uses Git line history to identify when the previous version of each qualifying line was introduced.
5. Classify additions and unmatched changes. New insertions and insertions left over after line pairing are classified as New Work.

Rework, Refactor, and New Work

• Rework: a qualifying changed line whose previous version was introduced less than 21 days earlier.
• Refactor: a qualifying changed line whose previous version was introduced 21 days or more earlier.
• New Work: newly inserted code and other changes that LinearB attributes to new development.

When a changed line originated from an earlier commit on the same branch, LinearB may classify the change as New Work rather than Rework. This keeps iteration on code being developed within the same branch associated with the original new-development effort.

Age Boundary

• Code younger than 21 days → classified as Rework
• Code 21 days or older → classified as Refactor

The 21-day threshold is fixed and cannot be modified.

Changes That May Not Count as Rework

Not every line that appears modified in a Git diff is counted as Rework. Examples include:

• Files removed by the applicable include or exclude rules
• Paired deleted and inserted lines with at least 90% similarity
• New or surplus inserted lines, which are classified as New Work
• Changes to lines introduced by an earlier included commit on the same branch, which may remain classified as New Work
• Changes to code that is 21 days or older, which are classified as Refactor

The similarity rule is intended to prevent minor or effectively identical edits from inflating the Work Breakdown. Examples can include a small version change, a nearly unchanged import statement, or another line whose before and after values are substantially the same.

How the Metric Is Calculated

Rework is calculated using the following formula:

(Rework lines ÷ Total classified code changes) × 100

Where:

• Rework lines are qualifying lines classified as Rework after file filtering, similarity comparison, line-history analysis, and branch-lineage classification.
• Total classified code changes are the qualifying changes classified as New Work, Rework, or Refactor after exclusions and ignored near-identical pairs have been applied.

The headline value represents the total number of Rework lines divided by the total classified code changes across all included branches in the selected time range.

This is a weighted percentage calculated across the entire selected time range. It is not an average of the individual daily percentages.

Worked Example

Suppose a qualifying diff block contains:

• Five inserted lines
• Four deleted lines

LinearB may classify the block as follows:

• One deleted/inserted pair is at least 90% similar, so that pair is ignored.
• Two remaining deleted lines were introduced less than 21 days earlier, so they are classified as Rework.
• One remaining deleted line was introduced 21 days or more earlier, so it is classified as Refactor.
• One surplus inserted line remains after pairing, so it is classified as New Work.

The classified result is:

• Rework: 2 lines
• Refactor: 1 line
• New Work: 1 line
• Total classified changes: 4 lines

The Rework percentage for this example is: (2 ÷ 4) × 100 = 50%.

A manual review of the raw diff may produce a different count because the raw diff still displays the near-identical pair that LinearB ignored.

How the Metric Is Displayed in the Dashboard

The metric card displays two types of values:

1. Headline value

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

It reflects the proportion of classified code changes attributed to Rework across all included branches during that period.

2. Time-based values in the chart

The line chart shows Rework aggregated by time bucket, such as daily.

Each point represents:

Rework lines ÷ Total classified code changes within that time bucket

Clicking a point displays:

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

Values are calculated independently for each time bucket. The daily percentages are not averaged to produce the headline value.

Why This Metric Is Useful

Rework can provide insight into:

• Initial code quality
• Clarity of requirements
• Effectiveness of review and collaboration cycles
• Iteration patterns during active development

High Rework may indicate:

• Late or unclear feedback
• Incomplete first submissions
• Reactive development patterns

Moderate Rework can reflect natural iteration during active development cycles.

How to Interpret Rework

Rework measures qualifying modifications to code introduced less than 21 days earlier.

It should not be confused with Refactor, which measures qualifying modifications to code introduced 21 days or more earlier.

If you want to understand the total volume of qualifying changes to existing code, review Rework and Refactor together. Looking at Rework alone excludes changes classified as Refactor.

Rework should also be evaluated alongside:

• PR Size
• Review Depth
• Time to Review
• Cycle Time

As general guidance, not a strict rule:

• Sustained Rework above 10–15% may warrant investigation.
• Extremely low Rework may indicate minimal iteration, but it may also result from the age, lineage, similarity, or file-filtering rules described above.

Context matters. Some domains and development practices naturally require more iteration than others.

Data Sources

Rework is derived from Git commit history, repository diff data, and line-level history.

The metric includes qualifying commits on included branches within the selected time range. Pull-request status—open, merged, draft, or without an associated pull request—does not determine whether a qualifying commit is included.

File-inclusion and exclusion rules are applied before the remaining changes are classified.

Applicable Configuration

Rework results may depend on:

• Repository and branch inclusion rules
• File-inclusion and exclusion patterns
• The available Git history for each qualifying line
• How deleted and inserted lines are grouped within Git diff blocks

The 21-day age threshold and 90% similarity threshold are fixed classification rules.

Limitations

• Rework measures classified change volume, not developer intent.
• It does not evaluate the quality of a code change or review feedback.
• Similarity detection reduces minor-change noise but cannot determine the business significance of a change.
• File filters can cause raw pull-request totals to differ from Work Breakdown totals.
• Git diff-block grouping and branch lineage can affect whether a change is classified as New Work, Rework, or Refactor.
• Small datasets may produce volatile percentages.
• Rework should not be treated as a standalone measure of code quality.
• Because Rework is commit-based, qualifying commits can be included regardless of branch lifecycle or pull-request association.

Why a Manual Count May Differ

To compare a manual count of changes to existing code with LinearB, review Rework + Refactor rather than Rework alone. Even that total may differ from the raw diff because excluded files, near-identical pairs, same-branch lineage, and diff-block pairing are applied before classification.

A manual Git diff or blame review often counts every visible deletion or modification whose previous version appears recent. LinearB additionally applies:

• Repository and file filters
• Diff-block pairing
• The 90% similarity rule
• The same-branch lineage rule
• New Work classification for surplus insertions
• The 21-day Rework-versus-Refactor boundary

As a result, the number of lines visible in a pull-request diff may not equal the number of lines classified as Rework.

Stakeholder Use Cases

Engineering Managers

• Detect excessive iteration on recently introduced code.
• Monitor review-process effectiveness.
• Identify patterns affecting delivery timelines.

Team Leads

• Improve first-pass submission quality.
• Coach teams on clearer feedback cycles.

Developers

• Reduce avoidable changes to recently introduced code.
• Improve alignment before submitting pull requests.

Reviewers

• Provide earlier and clearer feedback.
• Balance review thoroughness with efficiency.