At Exsilio Solutions we use Microsoft’s Team Foundation Server (TFS) 2010 for collaborative development and source control. TFS 2010 also has tools for work item management, offering nice templates for User Stories, Tasks, Bugs, and Test Cases – all elements of the Scrum project methodology we have adopted. Queries on the Team Explorer allow you to view groups of these items easily.
However, one aspect of TFS 2010 needs improvement – Team Queries. The out-of-the-box queries are good for individual developers, but not helpful for the team and project managers. Let’s take a look.

My Bugs, My Tasks, and My Test Cases are good for an individual developer or tester who has items assigned to them, but there’s not a great way to get visibility into all work items at once. That’s because the standard queries have the Assigned To = @Me value.

Also, these queries do not show any closed items. It’s a chore to see what was recently completed by the team, or report on features or bug fixes for past releases.
Product Backlog and Product Planning only deal with the User Stories, the high level containers for Tasks, Bugs, and Test Cases. Unfortunately, these queries only display the User Stories, which require clicking into the individual item, then browsing the links to see related child items. Not very efficient.

In review, the pain points:
- Difficult to see full list of tasks, bugs, and test cases in one place, across multiple resources.
- Hard to see closed tasks, for recently completed items, or reporting on past releases.
- Can’t focus in on a particular kind of work item, at a particular state.
To address these issues, we have created a standard query set we’re using in the Team Queries across a growing number of projects. All of these remove the @Me statement to see across multiple resources, and also target the specific states available for each work item type.

Bugs
We have four queries, three reflecting each individual state for bugs (Active, Resolved, Closed), as well as a query that shows all states together (essentially, All Bugs).
- All Bugs – Active
- All Bugs – Resolved
- All Bugs – Closed
- All Bugs – Open, Resolved, Closed
This is exceptionally helpful when preparing status reports, looking through open bugs to confirm they are still open, resolved bugs to see if they have been tested and deployed yet in a build, and closed bugs when the resolution is in a production build.
All Bugs – Active

Change “State=” to Active, Resolved, or Closed to make each query, and Save As… to make your queries for each. Note, if you’re saving to the Team Queries, you’ll need some sort of Admin permissions to write queries there for your team.


All Bugs – Open, Resolved, Closed
For this query, you can simply set these clauses:

Alternatively, you can put each state individually, but you will have to use the OR command on the second and third states, and group the query. This is unnecessary for All Bugs, but in case you need to group two of the three states together, this is how it would look:

Tasks, User Stories
Same principles apply for Tasks and User Stories, just different queries. Change work item type, and cycle through the states.
Tasks
- All Tasks – Active
- All Tasks – Closed
- All Tasks – Active and Closed

User Stories
• All User Stories – Active
• All User Stories – Active and Closed
(I do not use All User Stories – Closed here – we found it had little value. Optional for your needs)

You can also create similar queries for Test Cases. We’ll create these when we migrate our Test Cases to TFS over the next couple months.
Copying Queries Between Projects
Once you have queries set up in one project, copying them is simple. Since all the queries use @Project, they will automatically change references to the project you copied them in. It’s very simple: copy, paste and use, with no additional changes required.
1) Click the first query, then hold Shift and click the last query to select the range.

2) Right click > Copy

3) Right click “Team Queries” in a different project, then Paste.

Simple! You can repeat this every time you set up a new project for standard operation between teams that use different projects. This should streamline expectations for developers, and help with status reporting for project managers.