• Home
  • BVSSH
  • C4E
  • Playbooks
  • Frameworks
  • Good Reads
Search

What are you looking for?

Standard : Rework Ratio

Description

Rework Ratio measures the proportion of effort or work items spent correcting or redoing previously completed work, such as fixing bugs, resolving misunderstandings, or reimplementing features. A high rework ratio indicates issues with quality, definition of done, or alignment across the delivery lifecycle.

This measure can highlight inefficiencies in handoffs, misunderstandings in requirements, or fragile system designs that require repeated intervention.

How to Use

What to Measure

  • Total number of work items (e.g. user stories, tasks, PRs, deployments) tagged or classified as rework.
  • Total number of work items delivered in the same time period.

Formula

Rework Ratio (%) = (Rework Items / Total Work Items) × 100

You can also measure by:

  • Effort (story points, hours)
  • Type (e.g. defect fixes, refactoring due to poor design, test rework)

Instrumentation Tips

  • Tag tickets or commits in your issue tracker as "rework", "bug", or "redo".
  • Align with QA or code review annotations to identify common root causes.
  • Visualise trends across sprints or releases to identify improvement opportunities.

Why It Matters

  • Highlights waste: Rework is time that could have been spent on new value.
  • Indicates quality: Rework often signals fragile delivery practices or weak collaboration.
  • Supports retrospectives: Helps teams reflect on system, process, or communication gaps.
  • Guides coaching: High rework ratios in specific teams or domains may signal a need for support or intervention.

Best Practices

  • Use a consistent definition of rework and apply tagging rigorously.
  • Review rework trends during retrospectives and planning.
  • Prioritise root cause analysis for rework-heavy features or releases.
  • Improve upstream activities such as requirement refinement, pairing, or test-first development.

Common Pitfalls

  • Failing to differentiate between normal iteration and unnecessary rework.
  • Underreporting due to lack of tagging discipline or blame culture.
  • Treating all rework as avoidable rather than seeing it as a learning signal.
  • Using the metric punitively instead of constructively.

Signals of Success

  • Rework ratio decreases or stabilises over time.
  • Teams proactively analyse and address sources of rework.
  • The system of work (not just individual contributors) improves.
  • Defects and misunderstandings are caught earlier in the lifecycle.

Related Measures

  • [[Defect Escape Rate]]
  • [[Change Failure Rate]]
  • [[Time to Value]]
  • [[Lead Time for Change]]
  • [[Story Cycle Time]]

Technical debt is like junk food - easy now, painful later.

Awesome Blogs
  • LinkedIn Engineering
  • Github Engineering
  • Uber Engineering
  • Code as Craft
  • Medium.engineering