We answer one of the most common questions from our XBOSoft webinar on agile metrics.

Question: What does Technical Debt include?

Answer: The debt can be thought of as work that needs to be done before a particular job can be considered completeor “proper.” If the debt is not repaid, then it will keep on accumulating interest, making it hard to implement changes later on. Unaddressed technical debt increases software entropy and is usually as a result of poor system design. Think of all the things that you say “we’ll do that later”. That represents technical debt. Included in the list:

Static code analysis: This could be a simple as putting into continuous integration so that at minimum this is done, but many teams don’t. Another, we’ll do it later chore.

Code reviews and inspections: We don’t have enough time for this right? Only problem is, when we don’t review code, we get people implementing classes in ways we don’t want, variables declared in ways we don’t want, and possibly logic implemented incorrectly or not optimally. We’re not saying that review all code. But to keep with the agile principle of self organizing teams that build the best architectures, don’t you think there should be time to review what each other are building, discuss and come up with better ideas?

technical debt

Requirements reviews (prior to giving to developers): Many times, requirements come from the product owners and are explained in the planning meeting or grooming sessions. We don’t have to document for the sake of documenting but we do have to confirm our understanding to make sure we are doing what we think we are supposed to do. This is