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.