Every delivery dashboard I have ever reviewed counts the same thing: work that moved forward. Tickets closed, story points burned down, features shipped, releases cut. Not one of them counts the work that came back.
That gap is the most expensive blind spot in product delivery, and in late 2024 the research most engineering organizations trust finally gave it a name.
Rework rate, defined
DORA (the DevOps Research and Assessment program behind the annual State of DevOps report) added a new measurement in its 2024 research: rework rate. The team defined it through a single blunt survey question, asking roughly 3,000 practitioners how many deployments in the last six months “were not planned but were performed to address a user-facing bug in the application.” In other words: how often do you ship, watch it break something a customer touches, and ship again to fix what you just released?
The finding that made this more than a curiosity: responses to that rework question were highly correlated with change failure rate, the share of releases that need a hotfix, rollback, or patch. The correlation was strong enough that DORA restructured its framework around it. Time to restore service moved over to the throughput side of the ledger, and rework rate was added as a core factor of delivery stability.
For a product manager, the headline is simple. The industry’s most-cited delivery research now treats “how much of your shipping is really re-shipping” as one of the two numbers that define whether a team is stable. Most PMs cannot tell you their rework rate within a factor of two.
Why your velocity chart cannot see it
Here is the mechanical reason rework hides. When a shipped feature comes back broken, incomplete, or simply wrong, the correction almost never gets logged as “redo.” It re-enters the system as a fresh ticket: a bug, a fast-follow, a “small enhancement,” a P2 in the backlog. Velocity counts that ticket as new output. The burndown looks healthy. Standup sounds busy. The team is moving quickly, and half of the motion is going in a circle.
This is not a fringe cost. Stripe’s Developer Coefficient study, run with Harris Poll across more than a thousand developers and a thousand executives in five countries, found the average developer spends over 17 hours a week on maintenance work, and about four of those hours specifically fixing bad code. Stripe put the global opportunity cost of that four-hour slice at roughly $85 billion a year. Separate industry surveys land in a similar place, with developers reporting they lose somewhere between a quarter and 41% of their time to maintenance, debugging, and rework, and naming deadline pressure as the single most common cause.
Read that back as a delivery manager. If a meaningful share of your team’s week is spent servicing work that already shipped, then the roadmap you are presenting to stakeholders is quietly funded by a debt you are not showing on the balance sheet.
Rework is not the same as technical debt
It is worth separating two things that get blurred. Technical debt is a deliberate loan: you knowingly take a shortcut to hit a date, and you plan to pay it back later. That can be a perfectly sound decision, which is why technical debt is a product decision and not just an engineering one.
Rework is different. Rework is paying twice for the same feature because it did not land right the first time. The debt was a choice; the rework is a miss. You budgeted to build the thing once, and you are building it one and a half times. When PMs conflate the two, they excuse rework as “just debt we’ll get to,” and the reopen queue keeps growing because nobody is treating it as a signal that discovery, specs, or quality gates broke upstream.
The number that predicts whether a team is actually fast
In the 2024 benchmarks, elite performers run a change failure rate around 5%. Low performers sit far higher, north of 40% in some cuts of the data. That spread is the whole story of delivery speed. Two teams can post identical raw output, and the one with the lower rework rate is the one actually moving the product forward, because the other one is spending its afternoons re-shipping its mornings.
I saw this vividly on a fractional COO engagement a few years back. The delivery team had a reputation for velocity, and the charts backed it up: tickets closed at a healthy clip, sprint after sprint. What the charts did not surface was that a large fraction of those tickets were reopened work, features that had been marked done in a prior sprint and quietly bounced back through a bug or a “clarification.” Nobody was tracking the reopen. The moment we started tagging any ticket that touched already-shipped work and reporting it as its own line, the real throughput dropped by roughly a third overnight. That number was uncomfortable, and it was the most honest thing on the board. Within two quarters, tightening the definition of done and adding a lightweight pre-release check cut the reopen line in half, and actual delivered value went up without a single new hire.
You cannot manage what you refuse to count. Twenty-plus years in IT operations taught me that the metrics a team is proud of are rarely the ones telling the truth. Output is easy to celebrate. Rework is the one you have to go looking for.
Building the wrong thing is rework too
Everything above is rework at the execution layer: shipped, broke, fixed. There is a second, more expensive form that lives at the strategy layer, and product managers own it outright.
Pendo’s Feature Adoption Report, drawn from more than 600 real product subscriptions, found that roughly 80% of features in the average product are rarely or never used. The older Standish CHAOS research put the figure around 64%. Pick whichever number you find credible; both are damning. A feature that ships clean, breaks nothing, and gets adopted by nobody is not a win. It is rework in slow motion, because eventually someone will rebuild it, rip it out, or route around it, and all of that is work you paid for once to deliver and will pay for again to undo. Shipping the wrong thing correctly still lands in the rework column; the invoice just arrives later.
The practice: measure your reopen rate this cycle
You do not need instrumentation or a new tool to start. You need one honest hour with your issue tracker.
Pull every deployment or completed ticket from the last sixty to ninety days. For each one, ask a single question: was this planned new work, or was it an unplanned response to something already shipped, a bug fix, a rollback, a hotfix, a fast-follow to make a released feature actually usable? Count the second category. Divide by the total. That fraction is a working proxy for your rework rate, and it will almost certainly be higher than your gut estimate.
Then do three things with the number.
Bring it to your next delivery review as its own line, separate from velocity. The point is not to shame the team; it is to make the invisible visible. A team that can see its rework rate will start asking why things bounce back, which is exactly the upstream conversation you want.
Trace the biggest reopens to their root. Almost every one traces back to a decision made before code was written: an ambiguous spec, a skipped edge case, a validation that discovery should have caught, a release pushed past a quality gate to hit a date. That is where the fix lives. Rework is a lagging indicator of an upstream shortcut, which is why catching problems in the first 48 hours after you ship matters less than not creating them in the first place.
Protect the definition of done. Most reopen queues are inflated by work that was called finished when it was merely code-complete, the exact gap behind the 90% done trap. Tighten what “done” means, and a surprising share of rework never happens.
Speed in delivery is not how fast you ship. It is how rarely you have to ship the same thing twice. The teams that win are not the ones with the busiest boards. They are the ones whose work, once shipped, stays shipped.