Where do you record Technical Debt in TFS?

Question

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 separate 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?

Midian

I'm not sure how to do this, but it's a great question. It makes perfect sense that you should track your technical debt just like you track requirements. The problem I see is identifying the debt. If you can identify it accurately then you can make a work item to pay it back. – Chuvash

TFS == Team Foundation Server? It helps if you define acronyms. – Jer

Sorry - yes TFS === Team Foundation Server. I tried to mark it down between <abbr> tags, but they aren't supported in SO. – Midian

Answer 1

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.

Neisse

But don't you still need to associate a task with a particular iteration? Do you find that this approach is clean and easy to manage? What do you do for tasks that might span a couple of iterations? – Midian

I manage it like any other task--so yes, I find it clean and easy to manage. I haven't found it useful to break out "technical debt" as a separate area; in the end it really comes down to more work in existing areas. Sometimes the task goes in the current iteration; sometimes in another. As with all tasks, sometimes they can get postponed from the current iteration to the next as the iteration comes to an end. For tasks that can span more than iteration, I usually just break them up into multiple tasks (even something as simple as "phase 1" and "phase 2" generally works fine). – Neisse

I like your point about any technical debt ultimately having its "root cause" in an existing feature or area of the project. Good point. – Midian

@Neisse But do you have a feature for the tasks/user stories? Or just the user story with the task? – Pubescent

Answer 2

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.

Cockcrow

Thanks. This is the sort of approach I was curious about. But do you find it works well? Are there other people / businesses operating this way? Are your "Technical Debt" area and "Maintenance Backlog" iteration both at the top level of their respective hierarchies? – Midian

It works well in that the team can take a proactive approach, documenting technical debt as they go, even if they cannot fix it in the current iteration. I can also easily report on how much unanticpated work per cycle was due to technical debt etc. There is another company in our area (200 + developers) using a similar approach. I can't speak for the broader community, but it seems to leverage TFS as it was intended. – Cockcrow

Answer 3

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".

Pollination