Appearance
Rework Rate
Definition: Rework Rate measures the percentage of code that is changed within a short period (e.g., 2-3 weeks) after it was first written. It quantifies the amount of "wasted effort" spent modifying recent code, often due to bugs, unclear requirements, or integration issues.
Why It Matters
Rework Rate is a powerful measure of development quality and efficiency. A high Rework Rate indicates that work is not being done correctly the first time.
Quantifies Wasted Effort: It directly translates process problems into a measure of inefficiency. A 20% Rework Rate suggests that one-fifth of the team's recent coding effort was spent fixing or changing brand new code.
Indicates Quality Issues: High rework is often a symptom of insufficient testing, poor code review, or unclear acceptance criteria, leading to bugs and misaligned implementations that must be fixed immediately.
Highlights Planning Deficiencies: If rework is consistently high, it can signal that requirements are not being defined clearly enough before development begins, causing developers to build the wrong thing.
How to Measure It
Rework Rate is calculated by analyzing version control history to identify code that was recently changed.
Rework Rate = (Lines of Reworked Code / Total Lines of Code Changed) * 100
"Reworked Code" is defined as any line of code that is modified or deleted within a few weeks of its creation.
Interpretation
Goal: The goal is a low and stable Rework Rate. Some rework is unavoidable, but it should be the exception, not the norm.
Investigate Spikes: A sudden spike in Rework Rate after a release is a clear signal that the release had quality problems and should trigger a retrospective.
Compare to Churn: While
Code Churn
looks at long-term volatility, Rework Rate is focused on the short-term quality of new code. A file can have low churn but a high rework rate during its initial development.