Rework Metric

Definition

Rework measures the percentage of code changes that modify or delete lines of code that are less than 25 days old at the time of change.

It reflects effort spent revising recently introduced code.

Rework is calculated from commit-level changes across all included branches within the selected time range. PR status does not affect inclusion.

How the Metric Is Calculated

Rework is calculated using the following formula:

(Lines modified or deleted that are <25 days old ÷ Total lines changed) × 100

Where:

• Lines modified or deleted that are <25 days old = lines whose previous version was introduced within the past 25 days
• Total lines changed = lines added + lines modified + lines deleted

Line age is determined using Git history.

The headline value represents:

Total reworked lines ÷ Total lines changed across all included branches in the selected time range

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

Age Boundary

• Code younger than 25 days → counted as Rework
• Code 25 days or older → counted as Refactor

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

How the Metric Is Displayed in the Dashboard

The metric card displays two types of values:

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

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

It reflects the proportion of recently introduced code that was subsequently revised, across all included branches during that period.

2. Time-Based Values in the Chart

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

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

Clicking a point displays:

• The Rework 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

Rework provides 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 modifications to recently introduced code (<25 days).

It should not be confused with Refactor, which measures modifications to older code (≥25 days).

Rework should 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 or superficial review activity.

Context matters — some domains naturally require more iteration than others.

Data Sources

Rework is derived from Git commit history and repository diff data.

The metric includes all qualifying commits on included branches within the selected time range. PR status (open, merged, draft, or without an associated PR) does not affect inclusion.

Tunable Configurations

Rework behavior may depend on:

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

Limitations

• Rework measures change volume, not intent.
• It does not distinguish between minor edits and substantial rewrites.
• It does not evaluate the quality of review feedback.
• Formatting-only changes can inflate results.
• Small datasets may produce volatile percentages.
• Rework reflects change distribution, not code quality.
• Because Rework is commit-based, it includes all qualifying commits on included branches, regardless of branch lifecycle or PR association.

Stakeholder Use Cases

Engineering Managers

• Detect excessive post-review iteration.
• 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 post-review changes.
• Improve alignment before submitting PRs.

Reviewers

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