Generally speaking, there are 3 approaches to setup team projects in TFS: Team Project Per Application, Team Project Per Release, or Team Project Per Team.
What are the reasons that teams typically create multiple Team Projects? They do so because there are benefits to isolating and separating the various assets of each project/team, and creating a Team Project for each seems like the most intuitive way to achieve this.
However, the multiple Team Projects can cause significant hurdles if you ever wish to move data across a Team Project boundary. Team Projects are intended to isolate the data stored in each one, and there is no easy way to move some data such as source code and work items from one Team Project to another.
Nowdays most TFS experts have come to agreement in the past couple of years that one big Team Project for the entire Company is often the best choice, and in fact Microsoft is actively introducing new TFS features that make this approach easier.
Going with a Single Team Project avoids most of the above problems. You will obviously never need to move Work Items (or code) between projects. But now you have the challenge of how to organize data within the Single Team Project to provide separation and isolation. This is accomplished mostly through a combination of using the Area hierarchy and Teams functionality. If we imagine we combine what used to be multiple Team Projects into a single team project, we end up with many “sub-projects” (not an official term) within the single Team Project. We can create a root Area for each sub-project, a TFS Team for each sub-project, and a root source control folder for each sub-project. Then we can use the Area field to filter all reports and queries. Each Team is tied to the related Area and is used to provide each Team/Sub-Project with it’s own Product Backlog. And Security can be granted based on Area and/or Source Control Path.
TFS Teams
Create a TFS Team for each sub-project. You can create a hierarchy of Teams, so each sub-project could potentially have many teams each with their own Product Backlog, then then roll-up into the parent team for that sub-project.
TFS Security Groups
You probably don’t want to use the default TFS Security Groups (Reader, Contributor, Build Administrator, Project Administrator). If you give somebody the Contributor role, it will make them a Contributor across every sub-project which probably isn’t desired. What you should do is create those 4 groups for each and every sub-project. So if you have 5 sub-projects, you should end up with 20 TFS Security Groups (plus the original 4 that aren’t sub-project specific).
Areas
You should create a root area for each sub-project.
Iterations
Just like with Area hierarchy you should create a root node in the Iteration Hierarchy for each sub-project. Then you can maintain/manage the sprints/iterations for each sub-project separately.
Source Control
Create a root folder for each sub-project.
Work Item Security
Grant the various sub-project Security Groups permissions for the root Area associated with that sub-project. This will ensure that only members of that team can edit/view WI’s that belong to that teams’ Area(s).
Source Control Security
Just like Work Items, you should grant the sub-project Security Groups permissions only to the root folder associated with that sub-project.
Build Agents/Controllers
Ideally you would have a Build Controller for each sub-project, then one or more Build Agents/Build Servers for each sub-project. Having separate build-agents/build-servers for each sub-project has long been a good practice. This is because a team typically needs admin rights on their build server, and often need to install various software/SDK’s/frameworks/etc. onto the build server to support their build process. This is different for each team typically, so you usually don’t want to share build servers between teams. The separate build controller recommendation is to avoid the possibility of a team accidentally using another team’s build server. If we were to share a Build Controller, it is too easy to accidentally configure the build to use any build agent regardless of “agent tags”, but this will have the unintended behavior of using other teams/sub-projects build servers/agents. By forcing me to pick a sub-project specific build controller when setting up a build definition, this makes it harder to accidentally run into this situation.
Build Definitions
When you have a Single Team Project, you are going to end up with a very long list of Build Definitions since all sub-projects Build Definitions will all be mashed together into one list. In 2010 there used to be a tool called InMeta Build Explorer that would allow you to introduce virtual folders to organize them. That tool does not work in TFS 2012/2013, however there are new features built into TFS/VS that make things more manageable. You can now filter/search through the Build Definition list right in Team Explorer, you can also setup My Favorites and Team Favorites to make your most common builds more visible.
Work Item Queries
You can create folders to organize Work Item Queries. You should create a root folder for each sub-project, then assign permissions appropriately so each sub-project Security Group only has permission to it’s relevant WIQ folder.