Rework Rate

Rework Rate image
Rework rate is a quality metric that measures the share of a team's engineering time spent redoing work that was already marked as done or ready for release. It is usually calculated per sprint as rework hours divided by total engineering hours, and it shows how much effort is lost to learning things late.

Why it matters: Bug counts show how busy a team is before release, not how much damage could have been avoided. The earlier a team finds that its assumptions about requirements, user behaviour or configuration are wrong, the cheaper the fix. Rework rate makes the cost of late learning visible, and a rising trend says more about quality than the number of tickets closed.

In practice: Any work item that moves from Done or Ready for Release back to In Progress is tagged as rework, and the hours spent redoing it are logged. At the end of each sprint the team calculates the rate and watches the trend. Splitting rework into categories, such as requirement gaps and build or test gaps, shows where the problem starts.

Examples:

  • A team with 480 engineering hours in a sprint spends 88 hours on rework, giving a rework rate of 18.3 percent.
  • An approval workflow breaks when roles are reassigned mid-cycle, a scenario missed in refinement, costing 26 hours of rework.
  • A misconfigured validation rule in an import endpoint, where the requirement was clear but the code was wrong, takes six hours to correct.

Common pitfalls:

  • Counting reopened tickets instead of hours, which hides how expensive some rework is compared with others.
  • Assuming rework always means poor testing, when most of it may come from requirement gaps and unclear usage.

How do you calculate rework rate? Divide the hours spent redoing work that was already done by the total engineering hours in the period, then express it as a percentage.

Is a high rework rate a testing problem? Not necessarily. Splitting rework by cause often shows that most of it comes from committing to work before usage and edge cases are understood, which points to refinement rather than testing.
Explore MoT
Test Forward 2027 ยท Software Quality in the age of AI image
Tue, 19 Jan 2027
Test Forward is one afternoon at Station F with the QA and engineering people closing that gap in their own teams.
Improving Your Testing Through Operability image
Gain the tools you need to become an operability advocate. Making your testing even more awesome along the way!
Into The Motaverse image
Into the MoTaverse is a podcast by Ministry of Testing, hosted by Rosie Sherry, exploring the people, insights, and systems shaping quality in modern software teams.
Subscribe to our newsletter