TFS & Visual Studio ALM – by Neno Loje

(formerly Team System, VSTS)

Good Reasons to not create a new Team Project

November 12th, 2010 · 5 Comments · Team Foundation Server

Plan your Team Project strategy upfront!

Team Project strategy (questions like: How many Team Projects should we create? How to name them?) is important, because it’s mostly irreversible:

  • Team Projects can’t be renamed after creation
  • Team Projects can’t be split or merged easily (without lost of history)
  • Team Projects can’t be backed up, or moved to another server, individually

In general, Team Projects are supposed to be fairly large containers and you should avoid creating unneccessary new ones, because if you work with multiple Team Projects…

Reason 1: You can’t assign/move work items to another team project

You have a work item (Bug, Requirement, Task, etc.) that has been assigned to Team Project A, but actually belongs to Team Project B. You cannot assign/move it to the other team project.


You can create a copy of the existing work item, a new work item gets created in Team Project B (with a new Work Item ID),



those two work items are linked as "Related",



… you close the work item in Team Project A with an appropriate reason.


Reason 2: MS Excel and MS Project plug-ins can only show work items from a single team project

If you try to open a work item query in MS Excel or MS Project that contains work items from multiple Team Projects you will receive this message:


Reason 3: Changes to all team projects can siginificantly increase effort

For example if you want to change the check-in policy settings or work item type definitions in 10 or more Team Projects this can easily waste a lot of time and ultimately resulting in you writing scripts to automate the necessary steps.

Reason 4: Out-of-the-box reports show data from one Team Project only

The Reports supplied with the process templates MSF/Agile and MSF/CMMI 5.0 are only showing data from one team project, and offer filters like the Area, to only show data form a part of a Team Project.

Note: TFS might get slower with more than 250-500 team projects, depending on the complexity of the process template in use. You can read about the team project limit here.

However, there are still valid reason why you might want to create a team project:

Reason I: You need to use a different process template/methodology

You have to choose one process template per Team Project. If you want different work item types or a different process template you need a new Team Project.

Reason II: You need a separate Project Portal (SharePoint)

Alternatively you could create sub-portals or new document libraries on the existing portal.

Reason III: You need to work on a different schedule / Iteration Plan

Alternatively, since Iteration Path is a hierarchy you can add a new level to the existing iteration tree, but that can easily get pretty unmanagable as the tree grows.

But the way, you do not need a new Team Project for those reasons:

  • Security/Permissions: You can define fine-grained permissions within a Team Project on Areas (for Work Item Tracking), Folder (in Version Control) and Reports. (Note: You cannot hide the names of the areas, only their content. If you have secret area nodes, you might have to create a separate team project)
  • Version Control: Regardless of Team Projects you can move source code files and folders and create branches between Team Projects.


5 Comments so far ↓

  • Randy Farmer

    I have to disagree a bit on assigning work items across Team Projects. I have a few TFS clients where we do just that, and need different process templates on both projects. Example: One project with a more generalized/streamlined helpdesk ticketing system template with business users creating tickets as Work Item Only role users. Other projects using more traditional ALM templates for teams to manage their code in. Once a helpdesk ticket is triaged and determined to be a request for an LOB system, it is assigned to the right dev team.

    The trick is in how you write your work item queries. By default new and out-of-the-box queries all have a “Team Project = @Project” clause. Remove that, or better yet group it with an OR clause to include “Team Project = Other Project I care about”

  • Randy Farmer

    Also, if you need to archive a Team Project you can split it off into its own Project Collection (assuming you’re on 2010). I’ve used this functionality to deliver more than just the final snapshop of a client’s code, giving them the full revision history as well.

    Great article BTW! I 100% agree that most TFS shops initially over create Team Projects.

  • timmi

    Collection for each dev. team and dev. teams create team projects for each “new” product they engage.

    Do you think this is also “not recommended”?

  • neno

    @Timmi: Team Project Collections are technically separate databases, and thus the data is completely separated. It’s like installing a separate server.

    If this is what you want (e.g. you offer TFS Hosting within your company), than you’re good.

    If you want to copy over a work item, or branch code from one collection to another, that’s not possible.

    Remember: All Build Controllers/Agents and Test Controllers/Agents are bound to a single collection. You will need to have separate build/test machines for each collection.

    Summary: Usually a single collection is what you want (if there’s no good reason why you want it in a separate database).

  • neno

    @Randy: You are right. There are good reasons for creating a new team project as well. Especially if it’s not a development project, but a helpdesk or documentation project instead.

    Be aware that also if you remove the “Team Project = @Project” clause in a work item query, you still will not be able to get all those results displayed in MS Excel or MS Project – only in VS and TWA.

Leave a Comment