How to Measure Rework on Your Engineering Team (Jira, Linear, GitHub)

The percentage of production deployments that cause a service degradation requiring remediation.

Target range: DORA Elite: <5% | High: <10% | Medium: <15% | Low: >30%

Source: DORA State of DevOps 2024

The percentage of all defects that reach production, bypassing all pre-release detection.

Target range: Elite: <5% | Average: 12-18% | Worst quartile: >35%

Source: Capers Jones, Applied Software Measurement (2008)

The share of sprint story points spent on rework (bug fixes, hotfixes, regressions) rather than new feature work.

Target range: Elite: <10% | Average: 20-30% | Warning: >40%

Source: Derived from NIST 2002 benchmarks; applied to sprint-level data

The percentage of all defects removed before software is released. The inverse of escape rate.

Target range: Best-in-class: 95%+ | Typical: 85% | Warning: <75%

Source: Capers Jones, Applied Software Measurement (2008)

Query 1: Sprint rework ratio (current sprint)

project = "YOUR_PROJECT"
AND sprint in openSprints()
AND labels in (rework, hotfix, regression, bug-fix, rewrite)
AND status != "Cancelled"
ORDER BY created DESC

Sum story points from this result. Divide by total sprint story points. Multiply by 100 for your sprint rework ratio.

Query 2: Quarterly rework trend

project = "YOUR_PROJECT"
AND issuetype in (Bug, Task, Story)
AND labels in (rework, hotfix, regression, bug-fix, rewrite)
AND created >= startOfQuarter(-1)
AND created < startOfQuarter()
AND status in (Done, Closed)
ORDER BY created ASC

Run this for the last 4 quarters sequentially to see your rework trend. Decreasing story points per quarter is a positive signal.

Query 3: Defect escape tracking (production bugs)

project = "YOUR_PROJECT"
AND issuetype = Bug
AND labels in (production, escaped, incident-response, customer-reported)
AND created >= startOfYear()
ORDER BY priority DESC, created DESC

Count this result against total bugs found in the same period (including pre-release QA bugs) to calculate your defect escape rate.

Query 4: High-cost rework tickets (story points above threshold)

project = "YOUR_PROJECT"
AND labels in (rework, hotfix, regression)
AND story_points >= 5
AND created >= startOfQuarter()
ORDER BY story_points DESC

High-story-point rework tickets are your most expensive events. Review the top 10 in retrospective. What is the pattern?

Step 1: Create rework labels

In Linear: Settings > Labels. Create: rework, hotfix, regression, bug-fix, production-incident. Use a burnt-orange colour to make rework tickets visually distinct in the cycle view.

Step 2: Create the Rework saved view

In your team's Issues view: Filter by Labels (select all rework labels), Group by Cycle, Sort by Priority. Save as 'Rework Tracker'. Pin it to the sidebar for quick access.

Step 3: Weekly metrics pull

At end of each sprint/cycle: count rework issue points vs total completed points. Linear's Insights tab shows cycle completion data; filter by your rework labels to extract the subset. Record the ratio in a shared doc for trending.

Step 4: Monthly summary to leadership

Use Linear's export (CSV) filtered to rework labels for the rolling 30 days. Import to a spreadsheet to calculate sprint rework ratio and compare to the DORA benchmarks on this page.

PR label conventions

Add labels to every merged PR at one of: feature, bug-fix, hotfix, refactor, chore. Enforce via a required GitHub Actions check.

GitHub CLI query for monthly rework PRs

# Count merged rework PRs in the last 30 days
gh pr list \
  --state merged \
  --label "bug-fix,hotfix" \
  --json number,title,mergedAt \
  --jq '[.[] | select(.mergedAt > (now - 30*24*3600 | todate))] | length'

# Compare to total merged PRs in same period
gh pr list \
  --state merged \
  --json number,mergedAt \
  --jq '[.[] | select(.mergedAt > (now - 30*24*3600 | todate))] | length'

Goodhart's Law: measuring without thinking

Once rework rate becomes a team metric that management watches, engineers game it. Bug tickets get labelled 'feature enhancement' to avoid the rework label. Sprint velocity excludes rework tickets so the ratio looks better. Measure rework for diagnosis, not for performance review. Teams that tie rework rate to performance reviews will produce measurement fraud, not rework reduction.

Counting only tickets, not time

A 1-point bug ticket and a 13-point architectural rework ticket both count as 'one rework event'. Always measure rework in story points or hours, not ticket count. The ticket count metric systematically undervalues large rework events, which are the most important ones to understand.

Measuring the label, not the cause

Knowing your sprint rework ratio is 28% is useful. Knowing that 20 of those 28 points came from unclear acceptance criteria on three specific tickets is actionable. Rework metrics need a root cause column. Even a simple taxonomy (requirements defect / test gap / communication failure / tech debt) transforms the metric from a report card to a tool.

Not separating planned from unplanned rework

Tech debt paydown sprints, planned refactors, and post-launch UX improvements are sometimes tagged as rework. They should not be. Planned investment in code quality is not a failure; it is the opposite. Mixing it into rework metrics gives a misleading picture and demoralises the team members doing the right thing.