How Much Rework Does Your Project Perform?


In the last few weeks, several people have asked me how much rework is normal. Well, if you're working in a test-driven development environment, you probably have very little rework. My estimates for the few real test-driven projects I've seen is that they spend about 10-15% of their time on rework (finding problems and fixing them after the technical staff thought they were done with the particular feature. (This percentage may be this high because the technical staff were learning how to work in an agile way.) They spend lots of time on iterating through the requirements with the customer, which I don't count as rework.

But in the last few assessments I've done, and from other recent emails, my experience is that rework accounts for somewhere between 75% and 80% of a “normal” project's time. That's a huge drain from the project. The rework impedes forward progress. I know of these ways to reduce rework:

  • See how little you can do, and deliver that much as quickly as possible. The technique I use most often is to break the pieces into groups of requirements/features and then perform iterations within whatever lifecycle the people are used to.
  • Use peer reviews, walkthroughs, inspections, anything that forces more than one pair of eyes on the code.
  • Pair the testers with developers, or somehow get the testers to test the developers' code as soon as the product is built. Early feedback from testers can help developers prevent inserting more defects into the code.

All these techniques help developers focus on some small amount of work, and look for problems early in that work.

I wish I could say there was some reasonable amount of rework, but I don't know how to define that number. Any rework is a problem that you could have caught before. The question you manage is: how much rework should you prevent, and how much rework (time wasted) is ok? (For research-y projects, the answer is lots of rework is ok. For get-the-product-out-the-door projects, any rework is not ok. ) You're the only one who can answer that question for your project.

Leave a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: