Rework rate: the line that tells you when work is being redone, not shipped
Rework rate is the share of non-merge commits that rewrite lines changed within the previous 21 days — plotted weekly. It's a proxy for churn and instability, and it's blunt about it: lower is always better. Think of it as your codebase's version of "how much of this week did we spend re-doing last week."
Rework rate, weekly, holding in the good bands.
What it measures, and where the data comes from
For every non-merge commit, Deckgauge checks whether the lines it touches were also touched by an earlier commit in the prior 21 days. If they were, that commit counts as rework, not new work. Roll that ratio up weekly and you get one number: what fraction of this week's commits were rewrites of very recent work.
- GitHub — commits on connected repos, excluding merge commits, checked against the same repo's history in the trailing 21-day window.
- GitLab — same commit-level rewrite check, across every connected project.
- Azure DevOps — same window, pulled from the repos you've opted into code intel for.
21 days is deliberately short. It's long enough to catch "I shipped this two sprints ago and now I'm rewriting half of it," and short enough to not flag normal iteration on a feature that's still actively being built out.
How to read it
The shaded band at the top is Elite — under 15%. High is under 25%, Medium under 40%, and anything sitting above that is Low. Read the band first, the exact percentage second. A team quoting "22%" without knowing that's still High territory is missing the point.
Some rework is normal and healthy — nobody nails an interface on the first commit. What you're watching for is the line refusing to come back down, or climbing for weeks at a stretch. One noisy week after a gnarly feature is not a trend. Three weeks in a row is.
What it tells you over time
A flat line sitting in Elite or High is what a well-scoped team looks like — most work gets written once and stays written. When the line drifts upward and holds, it's rarely an individual performance problem. It's almost always a signal about the work itself: requirements that moved after coding started, a design that wasn't settled before the first commit, or a part of the codebase nobody can touch without breaking something nearby.
Because it's commit-level and weekly, this line reacts fast — faster than sprint retros, faster than bug counts. That makes it a good early-warning system: catch a climb at High, before it becomes a Medium-band habit that's much harder to unwind.
Example situations
1. Sustained thrash from unclear requirements
Six weeks climbing and settling well above the High band.
What you're seeing: the line crossed out of High in week two and has kept climbing since, now sitting deep in Low. Delivery doesn't look slow on a burndown chart — commits are happening constantly. But an increasing share of them are rewrites of code from two or three weeks ago.
How to react: this is thrash, and thrash is almost always upstream of the code — a spec that kept changing after work started, or acceptance criteria nobody actually agreed on. Don't respond by asking people to "be more careful." Go look at what changed in planning around the week this line turned.
2. Repeated spikes on the same module
A sawtooth pattern — spike, recover, spike again.
What you're seeing: the line isn't climbing steadily — it's sawtoothing. It drops back to Elite, then spikes into Low, then drops again. That pattern usually means one specific area of the codebase, not the whole team's process, is the problem.
How to react: check whether the spikes correlate with commits touching the same file or module each time — Deckgauge's commit history will show you this fast. If they do, you've found a fragile area: something nobody fully understands, that breaks a little every time it's touched, and gets patched rather than fixed.
Frequently asked
- What is rework rate?
- The share of non-merge commits that rewrite lines changed within the previous 21 days, plotted weekly. It is a proxy for churn and instability, and lower is always better.
- What does a rising rework rate mean?
- That a growing share of the week is spent redoing recent work rather than adding new work. Sustained increases usually point at unclear requirements or a fragile module rather than at careless engineers.
- Why 21 days?
- It is long enough to capture genuine rework on recent changes and short enough to exclude ordinary maintenance of older code, which is not churn.
Related widgets
- Bug Rate — confirms whether rework is also producing customer-facing defects.
- DORA Metrics — rework rate corroborates a rising change-failure proxy there.
- PR Size Distribution — oversized PRs are a common driver of the rewrite-it-later pattern.
- Back to the widget reference.
Last updated