Where do you record Technical Debt in TFS?

I'd like to find a way to record the Technical Debt we incur in TFS.

I need to record each item outside of a specific iteration to ensure that it is visible and easily-reported all the time. I've considered creating a se开发者_运维技巧parate Area for technical debt, but am unsure how well-suited that field actually is.

What are some common approaches that I might consider? Am I even barking up the right tree by trying to find a right place to put this?

I haven't found a need to track it separately; I just enter it as additional tasks. That way, they can be easily tracked and reported.

I find that there are several types of technical debt: Debt you know about and can track until fixed, and debt that becomes apparent as the result of an unexpected bug. I like to track the outstanding known technical debt in a separate Iteration I call 'Maintenance Backlog', under the area 'Technical Debt'. I can then link relevant bugs from ANY iteration to the Technical Debt area, while still tracking issues I cant resolve yet. The key is you still need bugs associated with the iteration they are found and fixed in and linked to the originating requirements for reporting purposes etc.

For what it's worth, I'm adding my 2¢ with a contemporary spin — Best practice for capturing Tech Debt work items in the backlog in Azure DevOps (the successor of TFS).

1. Use tags
Marking such tickets with a tech debt tag to indicate implicit value for the customer is always handy (e.g. to balance out the % of such tasks in the sprint).

2. Avoid tech debt features
There are 3 reasons to avoid tech debt features:

• Tracking purposes.
  An epic or feature needs a well defined goal to achieve, so it can be crossed off the list at some point to reflect the progress. Things like refactoring or tech debt related tasks is a never ending process, so bringing them under a feature would make it pointless for tracking progress.
• Violation of the single parent for tickets rule.
  It's convenient to practice a tree-like approach with a single parent feature for tickets and a single parent epic for features. There might be exceptions but they should be rare. Having multiple parents on tickets would trouble tracking progress.
• Tech debt tasks may belong to "real" feature.
  If a subset of tech debt tasks contributes to completing an ongoing or future feature / epic faster then keeping those tickets under that feature / epic makes sense. Combine it with a corresponding tag just in case. Of course, later when running out of time you may drop those tech debt tasks out.

3. Tasks without a feature is no crime
Tasks not always need a feature if you can manage them like this. Azure DevOps provides plenty of tools (e.g. querying on the tickets) to find and manage what you want.

Do what makes sense for the team and your project rather than "ticking a box".