What is a typical rework rate for a software team?

There is no universal benchmark worth trusting — definitions vary too much between teams. What we can say from measurement: teams calculating it for the first time are usually surprised, and meaningfully higher than they assumed. The useful comparison is your own baseline over time, not someone else's number.

Doesn't velocity already capture rework?

No — velocity hides it. Bug fixes and redone work earn points like any other work, so a team can hold steady velocity while an increasing share of it buys nothing new. That's exactly why rework has to be measured as its own category.

How often should we measure the cost of rework?

Establish the baseline over four to six weeks, then track it monthly as part of your delivery metrics. It moves slowly enough that weekly tracking adds noise, and it matters enough that quarterly is too late to react.

How to calculate the hidden cost of rework

Q: What counts as rework in a software team?

Any capacity spent achieving an outcome the team already paid for once: fixing defects in recent releases, reopened tickets, changes-requested cycles in review beyond the first pass, hotfixes, and redoing work because requirements were misread. Deliberate iteration during discovery is not rework — that's learning you chose to buy. Rework is paying twice for the same intended result.

A practical four-step method to put a monthly price on the work your team does twice — using data you already have.

Rework is the largest cost in most software teams that has no line item anywhere. Salaries are budgeted, tools are budgeted, cloud is budgeted — and the 20, 30 or 40 percent of capacity spent redoing things is absorbed silently into "how long things take". You can't reduce a cost you've never priced. Here's how to price it in four steps, with your existing tooling.

First, define what counts — and what doesn't

Rework is any capacity spent achieving an outcome you already paid for once: fixing defects in recent releases, reopened tickets, changes-requested cycles in review beyond the first pass, hotfixes, and redoing work because the requirement was misread or changed after build.

What doesn't count: deliberate iteration during discovery. Building a prototype, learning from it and changing course is learning you chose to buy — that's lean product management working as intended. The test: did we intend to do this work once, and are we now doing it again? If yes, it's rework.

Write your definition down before measuring. Teams that skip this step spend the review meeting arguing about categories instead of causes.

The four-step method

Tag the signals in your existing tooling. Reopened tickets, bug-type issues linked to recent releases, PRs with two or more changes-requested cycles, hotfix branches. No new tools — labels and queries in what you already run.

Measure the share of capacity over 4–6 weeks. Time spent on tagged items divided by total delivery capacity. An estimate from ticket counts and typical effort is fine — you're pricing a leak, not doing accounting.

Price it. Rework share × fully loaded monthly team cost. This single multiplication is the step almost nobody does — and the one that changes the conversation from "quality is important" to a number the CFO recognises.

Trace the top sources. Rework concentrates: a handful of causes — one unclear intake route, one fragile module, one rushed review path — usually produce most of it. Fix causes, not symptoms.

Worked example

Illustrative figures — the same example team as our delivery profitability page, not a client case. Replace every number with your own.

Team of 10 engineers, fully loaded cost NZ$1.8M/year — NZ$150,000/month.

Four sprints of tagged data: reopened and defect work absorbs 25% of capacity.

Price of the leak: 0.25 × NZ$150,000 = NZ$37,500/month — roughly NZ$450,000/year buying nothing new.

Source analysis: over half traces to two causes — requirements arriving without acceptance criteria, and one legacy module involved in most defect fixes.

A realistic first target — 25% → 15% in a quarter — recovers ~NZ$15,000/month of capacity: one full engineer, without hiring.

Where AI fits in this number

AI coding tools can move your rework rate in either direction. Used with explicit review, testing and quality standards, they catch defects earlier and cut reopened work. Used without them, plausible-but-wrong output and shallow review of high volumes push the number up — the mechanism we unpack in why AI can increase technical debt. If you adopted AI tools without baselining rework first, this measurement is the fastest way to find out which direction you're moving. The standards that control it are the AI engineering guardrails.

Reducing it: causes, in order of leverage

Clearer intake first — acceptance criteria before build kills the largest single source in most teams. Then smaller slices, which fail cheaper and get reviewed properly. Then review and testing standards sized so they actually happen, especially on AI-assisted changes. And underneath all of it, flow discipline: overloaded teams cut corners, and cut corners come back as rework. Notice that "tell people to be more careful" is not on the list — rework is a system output, not a diligence problem.