Agile has the idea of technical debt. An elaboration heard recently resonated with me. There are three kinds: design debt, quality debt and test debt.

Design debt is the more commonly thought of type of technical debt. You're compromising your current work in some way that will affect the future flexibility or maintainability of the system.

Quality debt is just another way to think about bugs in the system. I suppose you could also map them as "unintentional design debt". They are work you can either do now or defer until later, but that deferral has a cost in either maintainability, customer experience or business process disruption.

Test debt was the one that was most interesting to me. This is measured by the total time needed to regress the product after every iteration. This is the most insidious of the three types of debt. If you're developing software in an agile fashion, but you're not building automated tests to support the effort, this debt can grow without bound and it grows very quickly. It becomes either a crushing workload or an exercise in triage as to which parts of the regression suite are most important to run.

You can't ever have a project without some kind of debt (well, you could, but you'd either never ship anything useful or you'd never iterate enough to make it significantly better). However, being aware of how much debt you're carrying and thinking about the cost to your team's productivity is an important exercise.