Most leaders don’t budget for rework.
They budget for delivery.
But rework is where ROI goes to die.
Not the obvious kind (a bug that gets fixed). I mean the quiet, expensive kind:
- Work that gets started before priorities are clear
- Half-decisions that create “build it anyway” assumptions
- Context switching that turns a 2-hour task into a 2-day task
- “Just one more change” that restarts the loop
If you’re building an agile transformation business case, this is one of the clearest value leaks to explain because it shows up everywhere.
If you want the full ROI framing (inputs + a simple example + the Starter Kit), start here:
https://berriaultandassociates.com/resources/agile-transformation-roi/What “hidden work” actually is
Hidden work is effort that doesn’t appear as a project but still consumes real capacity.
It looks like:
- rework and defect fixing
- handoffs and waiting
- re-planning and re-explaining
- escalations and fire drills
- duplicate work across teams
- meetings that exist because the system is unclear
The problem isn’t that any one of these exists.
The problem is when they become the
default operating system.
The real cost of rework (in plain language)
Rework costs you in three ways:
- Capacity Time spent redoing work is time not spent delivering value.
- Delay Rework pushes everything else out. Even if your team is “busy,” value arrives later.
- Morale and sustainability Rework is demoralizing. It increases stress, reduces ownership, and makes good people leave.
That’s why rework is both a delivery problem and a leadership problem.
A simple way to estimate the cost (without precision theatre)
You don’t need perfect data. You need a defensible range.
Start with a quick assumption:
- Low: 5% of capacity is rework/thrash
- Likely: 10%
- High: 20%
Then translate it:
If your team has
N people and the fully loaded cost per person is
C, then the annual cost of rework is roughly:
$$ Rework Cost approx N times C times Rework $$
Example (simple on purpose):
- 20-person team
- fully loaded cost per person: C
- likely rework: 10%
Annual rework cost ≈ 20 × C × 0.10 =
2C That’s the equivalent of
two full people's worth of capacity.
Even if your numbers are off, the conversation is now grounded in something leaders understand.
What causes rework and thrash (usually)
Rework isn’t a team character flaw. It’s a system signal.
The most common causes I see:
1) Unclear priorities
When priorities shift mid-stream, work restarts.
2) Decision latency
Late decisions lead to incorrect assumptions, which in turn lead to rework.
3) Too much WIP
When everything is in progress, nothing finishes cleanly.
4) Weak “definition of done”
If “done” is fuzzy, work bounces back and forth.
5) Handoffs and silo boundaries
Every handoff is a chance to misunderstand, delay, or duplicate.
What to measure (so you can prove improvement)
You don’t need a perfect measurement program. Pick a few signals and track the trend.
Start with:
- Rework category in your work system (even if it’s a rough tag)
- Defect trend (severity matters more than count)
- Work item age (aging work often hides rework loops)
- WIP trend (thrash follows high WIP)
If you want a simple measurement plan, Article 2 covers the “hard to game” metrics: (link to your metrics post once published)
The behaviour-first fixes that reduce rework
This is where “behaviour-first, not framework-first” actually matters.
The fixes aren’t complicated. They’re just uncomfortable:
- Leaders protect priorities (and stop injecting work mid-stream)
- Teams limit WIP (and finish before starting)
- Decisions get owners and timeboxes
- “Done” becomes explicit (and quality isn’t negotiable)
- Reinforcement happens weekly (so the system doesn’t snap back)
Frameworks can support this.
But frameworks don’t enforce it.
People do.
If you want the “how we work” version of this, it’s here:
https://berriaultandassociates.com/about-us/why-we-work-this-way/A simple 30-day experiment (reduce thrash fast)
If you want a practical starting point:
- Pick one team
- Track WIP daily (a quick snapshot)
- Add a rework tag/category
- Set one WIP limit (even a soft one)
- Review rework causes weekly (15 minutes)
You’re not trying to be perfect.
You’re trying to make the hidden work visible.
That’s how you get ROI.
Next step
If you’re building a business case, rework is one of the easiest ROI inputs because it translates directly into recovered capacity.
Grab the ROI Starter Kit here (template + assumptions worksheet):
https://berriaultandassociates.com/resources/agile-transformation-roi/ And if you want help identifying the biggest ROI leaks in your system (without turning it into a huge program), book a quick call:
https://meetings.hubspot.com/jberriault
