Rework Is the Only Honest Metric Left

We shipped a stretch of work that looked clean the whole way through, and then spent the better part of the next cycle redoing a meaningful chunk of it. Nothing in the dashboards had warned me. Throughput was up, tickets were closing, the burn-down pointed the right way the entire time. The first honest signal I got that something had gone wrong was the rework itself, and it did not arrive as a warning. It arrived as a bill, after the fact, when the work was already done and had to be done again.

That sent me back to a question I had been avoiding: which of the numbers I report on do I actually trust now. Not which ones look good in a status meeting, which ones would have caught this. The answer embarrassed me a little, because the number I landed on is the one nobody puts on a wall, the one that does not fit on a dashboard, the one you have to go out of your way to even notice.

Velocity counts motion. Burn-down counts closed tickets. A demo shows the single path the agent was carefully walked down before you arrived to watch. Each of those was a decent proxy once, back when producing something took enough effort that you could not produce much in the wrong direction before the effort made you stop and look. The proxy worked because output and progress travelled together.

They do not travel together anymore. Producing the wrong thing got exactly as cheap and fast as producing the right thing, which means every one of those numbers can be at its healthiest in the precise week a project is heading somewhere wrong. A green chart is no longer evidence of health. It is evidence of motion, and motion is now free.

Rework is the exception, and the reason is structural, not clever. You cannot inflate it, because inflating it means doing real work twice, and nobody volunteers to redo work to make a chart look worse. Every other metric has a path to looking good that does not require the project to actually be good. Rework is the only one whose incentives point directly at the truth, because the only way the number goes up is if you genuinely had to redo the thing.

Not as a vanity dashboard with a trend line nobody reads. As a quiet, honest count: what did we ship, and then have to materially redo, and why. The "why" is where the entire value sits. Redo because the direction was wrong is one disease. Redo because the build was sloppy is a different one. Redo because someone changed their mind partway is a third. Three causes, three completely different fixes, and you only ever see the distinction if you write the redo down at the moment it happens instead of quietly absorbing it as "just how the work goes."

The reason almost nobody tracks it is that rework disguises itself as productivity. The team is busy, things are moving, and the second version of the feature shows up on the chart looking exactly like fresh output. It counts toward velocity. It burns down tickets. From any angle except the honest one, redoing a thing and building a new thing are indistinguishable, which is why the redo has to be deliberately tagged as redo or it files itself under progress and vanishes.

Because it is uncomfortable, and this year the uncomfortable number is reliably the true one. Rework measures the thing that actually became scarce, getting it right the first time, instead of the thing that became cheap, producing something that looks finished. A high velocity number buys you applause in the moment and tells you almost nothing about whether the quarter was real. A low rework number is quieter, harder to celebrate, and it is the one that would actually have caught the project I opened with, before the bill landed.

I am not saying throw the other numbers out. Velocity still tells you something about capacity and flow. I am saying stop treating any of them as a health signal, because a fast team pointed slightly wrong will show you the best numbers of its life right up until the rework arrives, and rework is the only one of them that was never able to lie.

So if your charts look healthy this quarter, here is the question I would sit with: would your real rework number make the team proud, or would it get quietly explained away in the meeting where someone finally thinks to ask for it?