The acceptance line for a returns-processing feature read: "items should be flagged for review." Four words short of usable. It didn't say by whom, or within what window. The vendor built a flag on the record. Ops needed a queue with an SLA and an owner. Nobody found the gap until UAT, six weeks after a demo where everyone in the room had called the feature done.
Rebuilding it didn't show up on the schedule as a failure. It showed up as a new ticket, sized like fresh work, billed like fresh work. On paper, nothing had gone wrong. Something had just been built twice.
Rework doesn't get counted as rework
Most programs track velocity, burn-down, percent complete. Almost none of them track how much of this sprint's "new" work is actually a second pass at something already marked finished last month. That's not an accident. Rework hides well inside a backlog, because a rebuilt ticket looks exactly like a new one once it's been re-titled.
Software rework, the work created by changing requirements, designs, or code after the build already started, typically eats 30 to 50% of total effort on a project. It isn't mostly caused by customers changing their minds. Most of it traces back to requirements that were incomplete, ambiguous, or inconsistent the first time they were written, and reworked code is roughly 2.5 times more expensive to produce than getting it right on the first pass, because altering existing work is slower than writing it fresh.
The incentive nobody puts in the RFP
Here's the part that doesn't get said out loud on most outsourced engagements. When a vendor is paid by the day, ambiguous acceptance criteria aren't purely a risk to them. A four-line acceptance section for a system with eleven integration points isn't tight scope, it's an opening. Every one of those four lines gets read differently by the vendor's QA and the client's, and both readings are defensible, because neither side wrote down enough to be wrong. I've sat in the room where that SOW was signed. Nobody was acting in bad faith. They were reading the same four lines and building different things, and the gap between those two builds became six weeks of paid rework that nobody wanted to call a mistake.
Fixed-price contracts have the opposite problem. Vague criteria there push the vendor to build the cheapest interpretation that technically satisfies the words on the page, then argue change control when the client wants the interpretation they actually meant. Either direction, the ambiguity is doing someone's job for them.
What to check before you sign off on "done"
Where acceptance criteria are quietly generating rework
- Read the acceptance criteria for the last feature that shipped. If it fits in one sentence and the feature touches more than one system, that sentence is almost certainly missing an owner, a threshold, or a timing rule.
- Ask the builder and the person accepting the work to each describe, separately, what "done" means for the current sprint. Compare answers before the demo, not after.
- Check whether any ticket closed last month has reopened under a different title. That's rework wearing a disguise.
- On outsourced work, notice whether ambiguity in the spec has ever worked in the vendor's favor. If it has, it will again, and the fix belongs in the contract, not in a strongly worded email.
None of this needs a heavier process. A one-sentence acceptance criterion is fast to write and fast to misread. The fix is writing the second sentence, the one that says who checks it, by when, and against what.
Tell me where "done" and "built" don't match
If work keeps getting redone without anyone calling it a mistake, that pattern is usually cheaper to fix at the acceptance line than after the rebuild.
Tell me where it's stuck