If any of you don't know about the concept of Technical Debt in your projects, this is a good presentation about it and how to handle it.
Some would say any code that doesn't have tests written for them is debt.
Also the broken window analogy from the Pragmatic Programmer, where if you have bad code the whole thing can start to fall apart is a good one.
Or if you have to do something quickly, and can't design or re-factor and much as you want, you might take on that debt with intentions of "paying it down" in a later sprint.
The debt analogy is easy to communicate to managers and other developers on your team and can improve your code quality and help your project stay alive. Pay down your debt!