Good Reasons to not create a new Team Project

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.

How to add a source control folder to an existing team project

When double-clicking the Source Control node of a Team Project that has no source control folder you receive the following message:

No Source Control Folder

Cannot open $/Projectname. Source control has not been configured for this team project, you do not have permission to acces it, or the team project has been moved or deleted.

The option to create a source control folder is gone!

What happened?
  • In TFS 2010 there is no option in the Team Project Creation Wizard to create a team project without source control (as it was possible in TFS 2008).
  • Therefore the prompt that asks if the user wants to recreate that folder, was removed as well.
  • Use the TFS Object Model, specifically:


  • Alternatively, I created a small command line utility that does exactly that.



Prerequisite: This tool requires Team Explorer 2010 to be installed.

(Thanks to Chandru R. from Microsoft for this tip and the support to resolve the issue)