Sprint Rework Percentage: The Simplest Defensible Metric

Updated May 2026. Companion to the measure page.

The Jira JQL query

The baseline query for total rework story points in the current sprint:

project = ENG
  AND sprint in openSprints()
  AND issuetype in (Bug, "Hot Fix", Regression, Defect)
  AND status = Done

Sum the story points from this query and divide by the total completed story points (the same query without the issuetype filter). For trailing analysis, replace openSprints() with closedSprints() and add a date filter:

project = ENG
  AND sprint in closedSprints()
  AND issuetype in (Bug, "Hot Fix", Regression, Defect)
  AND status = Done
  AND resolved >= startOfDay("-12w")

The Linear filter

Linear uses labels rather than issuetype for the rework distinction in most teams. The recommended setup: create labels for bug, regression, hotfix, and (for clarity, not rework) tech-debt-paydown. The filter query for the current cycle:

team:ENG
  cycle:current
  status:completed
  label:bug OR label:regression OR label:hotfix

Targets by team type

The three common measurement pitfalls

1. Counting tech-debt paydown as rework. Tech-debt paydown is prevention spend, not failure spend. Including it in the rework percentage inflates the number and obscures the true rework signal. The rework vs technical debt page covers the conceptual distinction; the operational follow-through is to give planned paydown its own ticket type and exclude it from the rework count.
2. Counting follow-up enhancement work as rework. A customer asks for an extension to a feature; the team builds the extension; some teams classify this as rework because it touches code that was previously shipped. It is not rework, it is new work. The distinguishing question is whether the original feature met its original acceptance criteria. If yes, the follow-up is new work; if no, it is rework.
3. Inconsistent tagging across teams. One team tags PR-revision-after-review as rework; another team treats it as normal sprint flow. The cross-team comparability dies the moment the tagging convention diverges. The cleanest measurement requires a single owner of the rework-tagging convention across the engineering organisation, with a quarterly review of how each team is applying the convention.

The reporting cadence

The two cadences that consistently drive behaviour change in practice are a weekly engineering-lead review of the trailing 4-sprint rolling average, and a monthly engineering-leadership review of the trailing 12-sprint trend. The weekly cadence is short enough to give the team rapid feedback on changes they are making; the monthly cadence is long enough to see real trends through the sprint-to-sprint noise.

The cadences that do not work well: daily dashboards (generate noise without insight, because rework rates have meaningful sprint-to-sprint variance), and quarterly reporting (too slow to give the team feedback on the experiments they are running). The first time a team measures rework, the rate often appears alarmingly high; this is usually because the previous baseline was invisible, not because rework has suddenly worsened. Resist the temptation to react to the first measurement; wait for the trailing 4-sprint baseline to stabilise before drawing conclusions.

Sources

• Google DORA. State of DevOps Report 2024.
• NIST. Planning Report 02-3. RTI International, 2002.
• Jones, C. Applied Software Measurement. 3rd ed. McGraw-Hill, 2008.
• Atlassian. Jira Query Language (JQL) documentation. support.atlassian.com.
• Linear. Linear filter and view documentation. linear.app/docs.

Frequently asked questions