Software factory rework

Rework consumes capacity

Rework is not simply any later change to the same area. Maintenance and planned iteration can be valuable work. Rework describes effort caused by an earlier result not being usable, correct, complete, or still relevant. Define the relation between the original and follow-up change before counting it.

Sources of rework can appear anywhere in the value stream. A requirement may be unclear, a review may miss a design problem, a test may fail to represent production, or a release may require an urgent fix. A high rework signal can therefore reflect a quality problem, a product learning cycle, or a classification change.

Read rework with stability and quality

Use rework with change failure rate, deployment rework rate, escaped defects, review findings, change size, and work mix. Compare similar services and periods. A lower rate after a drop in deployment activity may not represent improvement. A higher rate during a migration may be expected if the work is being refined intentionally.

Do not assign rework to an individual as a performance score. Rework is evidence about the path and its feedback, ownership, and decision conditions.

How Weave can help

Weave can connect follow-up changes to the pull requests and review context that preceded them. This lets teams examine examples behind a rework trend and choose a system improvement, while deployment and incident data establish production impact.