Most engineering leaders underestimate how much capacity their squads lose to work that gets done twice. Rework rate measures the proportion of engineering effort spent fixing, revising, or redoing work that was already considered complete. High rework rate quietly drains velocity, inflates cycle times, and erodes squad morale before anyone names the problem. This page covers how to define, measure, and benchmark rework rate, plus concrete steps to bring it down.
Key takeaways
- Rework rate measures the share of engineering effort consumed by fixing or redoing work that was already completed, and it matters because high rework quietly compresses the capacity available for new feature delivery without ever appearing on a sprint plan.
- The standard formula is: Rework Rate = (rework commits or issues / total commits or issues) × 100. No single published industry benchmark exists, but teams consistently delivering below 10% rework are considered high-performing, while rates above 25% typically signal systemic process gaps in review, planning, or requirements quality.
- The most common mistake teams make is treating rework as a people problem rather than a process signal. High rework rate almost always points to upstream issues: vague acceptance criteria, insufficient code review depth, or inadequate test coverage, not individual player performance.
- DevStats surfaces rework rate signals automatically by connecting to your Git provider and issue tracker, with benchmarks against 1,000+ engineering teams. Start a free trial to see your team's numbers in under two minutes.
Rework rate definition
Rework rate is the percentage of engineering work that involves fixing, revising, or redoing something that was previously marked complete. It captures unplanned corrections: bug fixes on recently shipped code, PRs that require significant revision after review, and issues reopened after closure.
Technically, it is calculated as: Rework Rate = (rework items / total work items) × 100. Rework items are typically identified by commit patterns tagged as bug fixes, issues reopened within a defined window, or PRs that return to a prior stage in the review process. Tracking this metric with your code review data gives you the clearest signal of where quality is breaking down in the delivery pipeline. When rework rate climbs, engineering investment that should fund new capabilities is silently redirected to maintenance, which compounds over time into missed roadmap commitments and stakeholder friction.
Why rework rate matters for engineering teams
When squads do not track rework rate, the cost stays invisible. Engineers are busy, sprints look full, and velocity numbers seem reasonable until the team misses a delivery date and no one can explain why. Untracked rework absorbs sprint capacity without appearing in planning, which means your planning accuracy degrades for reasons that look like estimation failure but are actually quality failure.
Rework rate connects directly to the KPIs engineering leaders are accountable for. High rework inflates PR cycle time, which you can explore in DevStats to see where revision loops are adding the most delay. It reduces throughput, because players are cycling back through completed work instead of moving forward. And it drives burnout: nothing erodes squad morale faster than repeatedly fixing work that should have been done right the first time.
Within the SPACE framework, rework rate sits at the intersection of quality and efficiency. It is a process signal, not a performance judgment on any individual player. Measuring it is the first step. What you do with that signal is where engineering leadership makes the difference.
How to measure rework rate
The most reliable approach combines two data sources: your Git provider and your issue tracker. From Git, you identify commits or PRs tagged as bug fixes, hotfixes, or reverts within a defined time window after the original work was merged. From your issue tracker, you count issues reopened within 30 days of closure. The combined formula is: Rework Rate = (rework commits + reopened issues) / (total commits + total closed issues) × 100.
No single universally published benchmark for rework rate exists the way DORA benchmarks exist for deployment frequency or change failure rate. The table below reflects qualitative thresholds observed across engineering teams, and actual targets will vary by team size, codebase maturity, and release cadence. You can compare your numbers against peer teams using DevStats benchmarks.
| Performance level | Rework rate benchmark | What it signals |
|---|---|---|
| Elite | Below 10% | Strong review practices, clear acceptance criteria, high test coverage |
| High | 10–20% | Healthy process with some room to tighten review or requirements quality |
| Medium | 20–30% | Systemic gaps in review depth, test coverage, or requirements definition |
| Low | Above 30% | Significant process breakdown; rework is consuming new delivery capacity |
Note: these thresholds are qualitative and should be treated as directional. Benchmarks vary by team size, codebase age, and release model. Use them as a starting point, not a hard target.
Rework rate in practice: a real example
A VP of Engineering at a 40-person SaaS company noticed that sprint velocity looked stable but roadmap delivery kept slipping by one to two weeks every quarter. She pulled issue cycle time data and saw that a disproportionate share of closed issues were being reopened within two weeks of closure. Her team's rework rate was sitting at 28%. The pattern was concentrated in one squad responsible for the payments integration, and the reopened issues were almost always tied to edge cases missed in the original acceptance criteria.
She did not reassign players or call out individuals. Instead, she changed the definition of "ready" for that squad: no issue entered development without at least two acceptance criteria covering error states. She also added a lightweight async review step for payment-related PRs before merge. Over the next two sprints, rework rate in that squad dropped to 14%. She tracked the change using issue cycle time data to confirm that reopened issues were declining, not just being reclassified.
How to improve rework rate
- Tighten acceptance criteria before work starts. Most rework originates in requirements gaps, not execution gaps. Require that every issue includes at least two edge case scenarios before it enters a sprint. This is the single highest-leverage change most squads can make. Watch your sprint reopened issue count as the leading indicator.
- Audit your code review depth, not just coverage. A PR that gets approved in under five minutes on a complex feature is a rework risk. Review your code review data to identify patterns where fast approvals correlate with later bug fixes. Set a squad norm for minimum review time on high-complexity changes.
- Classify rework explicitly in your issue tracker. If you are not tagging bug fixes and reopened issues consistently, you cannot measure rework rate accurately. Add a "rework" label or issue type and make it a sprint ceremony habit to apply it. This takes one sprint to implement and immediately improves signal quality.
- Connect rework rate to your change failure rate. Rework that makes it past review and into production shows up as a higher change failure rate. If both are elevated, the issue is upstream in requirements or review. If rework is high but change failure rate is low, your review process is catching problems but too late in the cycle.
- Review allocation patterns. Squads spending more than 30% of capacity on unplanned work, which you can surface through allocation data, often show elevated rework rate as a downstream symptom. Rebalancing planned versus unplanned work is a prerequisite for sustainable rework reduction.
Rework rate vs. change failure rate
Rework rate and change failure rate both measure quality problems, but they capture different failure points in the delivery process.
| Rework rate | Change failure rate | |
|---|---|---|
| Measures | Proportion of work that requires revision or correction | Proportion of deployments that cause a production incident |
| Starts when | Work is marked complete or merged | A deployment is made to production |
| Ends when | The corrected work is re-merged or issue is re-closed | The incident is resolved or the change is rolled back |
| Best for | Diagnosing upstream process gaps in review and requirements | Measuring production stability and deployment risk |
Use rework rate to diagnose problems before they reach production, and use change failure rate to measure how often those problems escape into live environments.