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 especially important where team members are speaking a 2nd language. None of us have that though…

Test case documentation: With agile, we’re supposed to have minimal documentation, right? YES, but we still need some documentation and with some structure otherwise we lose flexibility in assigning people to the job. We can’t expect everyone to have knowledge in their head on how to do things. If you have test cases residing in someone’s head, that’s debt.

Defect analysis: In the webinar, we talked a lot about this. This could be part of the retrospective where each sprint examines the previous sprint’s defects. Figuring out where mistakes are made is critical to improving. If you are gaining weight, then you need to look carefully at what you eat right?

Code refactoring: Many times, we know what design is best, but we choose the easiest way (which may not be the best for future flexibility) because it’s fast. We should go back and fix that stuff but there never seems to be the time. This could include code or database issues as well.

Whenever you put off something or say “we’ll do this this way because it’s quicker and change it later”, that means you are delaying technical excellence, a key principle in agile. Sometimes ‘working software’ and technical excellence contradict each other, but they shouldn’t. XBOSoft Measuring technical debt is another story…

BUT, If you are interested in Agile Quality Metrics, check out one of our most popular White Papers. Download below.