Ron WilsonTechnical debt is a term that is used in Extreme Programming or Agile methodology. Technical debt refers to the refactoring of code due to poor system design. In Agile, speed is a priority and often the programmer doesn’t have the full understanding of the complete scope. As additional changes occur, this requires the programmer to change the code to meet the revised requirements changes. In Agile, there is an understanding that a certain percentage of technical debt that will have to be carried over within the Sprints until the project is complete. It is important to gain an understanding of what that percentage is and the Agile team needs to keep a close watch on that.
From a quality perspective there is a correlation between the amount of technical debt and the quality that will be delivered for the customer. I refer to that as Quality Debt. If you are running a large project it is important to keep an eye on the number of defects that are being carried over at the end of each Sprint. Take a look at the following graph:
As you can see the amount of technical debt is accumulating due to the fact that more defects are being opened (black line) compare to the defects that are being closed (blue line). This is a result of poorly defined requirements or poorly developed code.
It is important to have metrics around quality within sprints so you can ensure quality is delivered to your customers. A poorly built application that has significant technical debt will be a miserable experience for everyone involved.
If you would like more information on Agile, DevOps or Software Testing, please visit my Software Testing Blog or my Software Testing YouTube Channel.
