The True Cost of Rework: How Engineering Teams Lose 33% of Their Time

Capers Jones (Applied Software Measurement) documents rework consuming 20-40% of total development effort in typical organisations. NIST Planning Report 02-3 (2002) separately found that identifying and correcting defects accounts for roughly 80% of development cost. DORA 2024 change failure rate data shows elite teams keep rework-related failures below 5% of deployments, while low performers exceed 30%. 25% is the most widely cited planning estimate and is the calculator default.

A good rework rate is below 10% of engineering effort, the level DORA 2024 elite performers sustain. The typical range is 20 to 40% (Capers Jones, SPR data), and consistently above 50% marks a struggling team (DORA 2024 low performers). Rework rate and rework percentage are two names for the same metric: the share of development effort spent redoing work that failed to meet a knowable requirement on the first attempt. Measure it as reworked story points or tickets divided by total delivered, per sprint.

The simplest formula: annual rework cost = team size x fully-loaded cost per engineer x rework percentage. A 20-person team at $200,000 fully-loaded cost with 25% rework spends $1,000,000 per year on rework. The formula page covers two more rigorous methodologies: bottom-up ticket analysis and defect escape rate calculation.

The 1-10-100 rule holds that a defect costs $1 to fix in design, $10 in development, and $100 in production. Barry Boehm's cost-of-change curve in Software Engineering Economics (1981) is the foundational source. IBM Systems Sciences Institute popularised the specific multipliers in the 1990s. Modern teams with strong CI/CD pipelines often see smaller ratios, but the directional principle holds consistently across virtually all studies.

Rework is the act and cost of doing work again because the first attempt failed a knowable requirement. Technical debt is the accumulated state -- shortcuts, deferred refactoring, missing tests -- that makes future changes more expensive. They compound: high technical debt raises the cost of every rework event. Ward Cunningham coined the technical debt metaphor in 1992; Martin Fowler's quadrant (2009) provides the most useful modern taxonomy.

Agile reduces wasted rework by surfacing requirement mismatches early in short iterations. However, raw rework rates can appear higher in Agile because the methodology makes rework visible that Waterfall hides until UAT. The key distinction is between necessary learning (agile iteration) and preventable failure (rework). The agile vs waterfall page covers this nuance with data from the Standish Group CHAOS Report and VersionOne State of Agile 2024.

The four metrics that matter: change failure rate (DORA), defect escape rate, percentage of sprint on bug fixes, and rework ratio by ticket type. The measure page provides copy-pasteable Jira JQL queries and Linear custom views for each metric, plus the 3-metric starter pack for teams new to rework measurement.