Take the 2-minute tour ×

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?

share|improve this question
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. –  Mark Ewer Dec 21 '09 at 1:19
TFS == Team Foundation Server? It helps if you define acronyms. –  S.Lott Dec 21 '09 at 1:49
Sorry - yes TFS === Team Foundation Server. I tried to mark it down between <abbr> tags, but they aren't supported in SO. –  Phil.Wheeler Dec 21 '09 at 2:25
add comment

2 Answers

up vote 4 down vote accepted

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.

share|improve this answer
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? –  Phil.Wheeler Dec 21 '09 at 2:19
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). –  RickNZ Dec 21 '09 at 3:43
I like your point about any technical debt ultimately having its "root cause" in an existing feature or area of the project. Good point. –  Phil.Wheeler Dec 23 '09 at 10:58
add comment

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.

share|improve this answer
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? –  Phil.Wheeler Dec 21 '09 at 2:16
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. –  PortageMonkey Dec 21 '09 at 2:29
add comment

Your Answer


