Based on my observations and experience, I believe the following to be the business case for paying down Tecnical Debt.
- The acronym "DRY" stands for Don't Repeat Yourself.
- Code Coverage means the lines of code exercised by automated tests.
DRY code yields full percentage gains in productivity.
If you have 100% duplicated code and clean it up to 0% (purely hypothetical) then your productivity improves by the same 100%. In other words, what took a team of 8 now takes a team of 4 because the amount of code to wade through is half. If your team did 16 points per sprint, they can now do 32.
Thus,
PRODUCTIVITY = MAX_PRODUCTIVITY * (1 - DUPLICATION)
Example: Team currently does 20 points, has 30% duplicate code. Their maximum productivity is...
20 = MP * .7
MP = 20 / .7 = 28 points
This means the team could work on lowering duplication from 30% to 0% to bring up their productivity from 20 to 28. Now size what kind of effort that would take to reduce duplication in order to make the right business decision.
Code Coverage yields half percentage gains in productivity.
If you have 0% Code Coverage and write unit tests so that it reaches 100% (purely hypothetical) then your productivity improves by 50%. This is due to the fact that while unit tests reduce defects and rework, it creates more code to maintain. In other words, what took a team of 8 now takes 6 because you can modify code, refactor safely, and add tests more easily. If your team did 16 points per sprint, they can now do 24.
Thus,
PRODUCTIVITY = MAX_PRODUCTIVITY * .5 * (1 + CODE_COVERAGE)
Example: Team currently does 20 points, has 30% code coverage. Their maximum productivity is...
20 = MP * .5 * (1 + .3)
MP = 20 / .65 = 30 points
This means the team could work on increasing code coverage from 30% to 100% to bring up their productivity from 20 to 30. Now size the effort it would take to write that many unit tests in order to make the right business decision.
Please let me know your thoughts.
.
