Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

I have just moved to a new company and they are using TFS 2010 (2012 in a couple of months) as their version control system and recently started to use it as a work tracking system for the developers.

However, there doesn't seem to be a bug tracking system for use by people outside development & test. Production support are getting reports of issues, fixing them on the fly and reporting back to their users at the moment. This needs to be changed but I don't really want to have a sperate system for tracking bugs and tracking dev work.

Is there a way that I can create a very light weight way of entering bugs into TFS similar to the way that FogBugz does? Logging into TFS to fill out a bug report seems to be a lot heavier and you have to associate it with a particular application. Support may be able to do this but I want to be able to triage the item and potentially change the association to something other than an application.

I have used FogBugz in the past and when adding a bug, you can add a much/little as you want to the item so it is at least recorded and later you can bounce it back to get more information when you come to triage the ticket.

share|improve this question
It's worth noting that if you're using TFS and all users have a Windows domain account, then they never have to "log in to TFS". Going to your team's TFS web portal will automatically log them in using the domain credentials for the current Windows user. –  17 of 26 Jul 25 '13 at 17:45
How did you end up solving this? Have the same issue today, need a ticketing system, have on-prem TFS2013. What I want is UserVoice, but would have to go away from on-prem TFS into VSO to get that integration. –  EJA Sep 14 at 19:54
@EJA - In the end we decided that we needed to go use a process of having the issue being raised through an email inbox which is picked up by the testers so they can fully document the issue, steps to re-produce, environment, etc and then the tester can add the bug to TFS in the correct format. Whilst it would have been nice for the users to have been able to add them direct, we realized that users are unlikely to give the developers all of the details they would need and would not look for duplication of the issue. –  Penfold Sep 15 at 14:08

4 Answers 4

It largely depends on what fields you would want, as 17 of 26 indicated: TFS is highly customisable. The reason I would want to do this as opposed to use something like JIRA is that you get a single view of what your developers are working on, as opposed to having to aggregate two systems.

TFS also has resource capacity planning, and if you're not showing production defects in your planning (and they take up a significant fraction of your time), then you're not really planning your capacity. I would in fact say that this is an ideal solution for teams where the developers make use of TFS and support Production (e.g. DevOps).

It doesn't mean you can't use other tools for the main Production Support/ITIL work, you'd just need to make sure they integrate, either manually or preferably automatically. Most such tools allow you to put in custom hooks, and TFS certainly does.

Anyway, to the main question. I use the CMMI TFS templates (which actually work fine with Agile BTW), and I just added a single field to one of the drop downs.

Here are the steps:

Install TFS Power Tools

Open the Work Item Template from the server

Open Work Item Template from server

Open Bug template

Edit the Discipline field

The discipline field is the "kind" of work related to the defect. The standard values are:

  • Analysis
  • User Experience
  • User Education
  • Development
  • Test

What we're just going to do is add "Production" to that list. First, edit the Discipline field:

Edit Discipline

Then, click the Rules tab and edit the ALLOWEDVALUES rule:

enter image description here

Then, Click "New", and add in "Production" as one of the values.

enter image description here

Click "OK" repeatedly until you're back at the field list.

Save the Work Item Template

OK, now you're done. You can create new Bugs and indicate their type as Production. I'd also create a few Work Item Queries looking at Production defects, and add them to your pinned items. Finally, look at the existing Bug queries, and maybe change their ordering so that "Production" bugs come up first (if that's possible).

share|improve this answer
Great, you've customised TFS to allow the devs to see "production bugs"... how does the production team (who are not part of the dev team and don't have VS) get to enter and manage them? –  gbjbaanb May 14 at 9:30
Well, for starters, they can access TFS via the web interface, using the Stakeholder license which is free. At our organisation we track Production incidents via an ITIL based system, but are integrating it automatically with TFS, as my answer indicated in the third paragraph. –  Sean Hederman May 14 at 17:58

No, that's right - Microsoft's premier ALM isn't really useful outside of Visual Studio and the dev teams.

You can access the work items using the Team Explorer (which is a very cut down version of VS) or access it via the TFS web site. Neither are particularly good options as the bug fields are reminiscent of ancient 'enterprise' bug trackers I had the misfortune to use in the past.

There's no real distinction between bugs in TFS - there's only the single tracker that you filter using a field in the item itself, so use a category field and then create a report that only shows a particular type of category. I think that's your only realistic option with TFS.

If you want external issue tracking, then I think TFS is a poor choice, you're better off using something like Jira or Redmine and using that to manage bugs - their interfaces are much, much nicer and easier to use than TFS. I particularly liked the way you can send an email to Redmine and it creates a new issue for you, that was an ideal usability feature for off-site workers.

share|improve this answer
The fields in TFS are fully customizable and the defaults depend on the process templates you pick when configuring TFS. The scrum template defaults to having Product Backlog Items, Tasks, and Bugs. Each work item type has different fields appropriate to the work. –  17 of 26 Jul 25 '13 at 14:43
@17of26 I know - the fields you use are fully customizable, but then so is Excel if you used that as a bugtracker. The OPs problem was that the template only gives you those work item types - and you cannot have different ones (eg a feature request, or external bug), you have to customise (or copy) one of the existing ones and use that - which in turn gives rise to a vast amount of configuration that you have to do to fit it into your workflows. So how do you have multiple bug trackers? –  gbjbaanb Jul 25 '13 at 15:56
I thought the OP didn't want multiple bug trackers and was just trying to figure out how non-devs could interact with the TFS work item tracking that the developers were already using (which to me is how you'd want to do things). –  17 of 26 Jul 25 '13 at 17:42
that's it - you can't really, or at least not nearly as easily as you can using other tools like Redmine or Fogbugz that have better tracker features. TFS has things like bug tracking added to it, but it's still primarily a developer-only tool. Redmine for example, has multiple trackers only in that there are multiple views of a single tracker DB. I think that's more what he wants than to use different tools (eg using TFS for devs and Fogbugz for support staff, for example). –  gbjbaanb Jul 26 '13 at 7:45
You can add as many custom work item types as you like. –  MrHinsh Jun 15 at 21:47

Non developer users can access the TFS work item tracking system by using a web browser to go to the Team Project Portal. To find the URL, go to Team->Show Project Portal in Visual Studio. From there, anyone with permissions can browse, create, or modify work items. They can also generate all kinds of reports to look at the status of things.

The types of work items available and the fields in the work items vary depending on how TFS is configured (primarily by which process templates were chosen).

The information required to enter a bug is also dependent on how you have TFS configured. In our case, we require a title, steps to reproduce, and the build that it was found in. The TFS work item tracking system is very powerful and flexible. It can be as complicated or as simple as you want it to be - it all comes down to how you have it set up.

share|improve this answer

This Microsoft blog post describes planned improvements in TFS that should help support lower-overhead:

  • New work item form that's easier on the eyes and includes discussion and mention options, similar to facebook and twitter.
  • Custom fields
  • Improved Kanban support, eg quick add tasks on a work item.
  • Also mentions dashboards and metrics.
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.