When should I create a new Team Project?
One thing I've noticed when working with Team System and customers is that there's a lot of confusion about when new Team Projects should be created. On top of that, there's a hard architectural limit of about 500 Team Projects on any Team Foundation Server. So it's in your best interest to prevent an unnecessary explosion of Team Projects.
Jason Barile has a great post outlining some of the things to consider when you're thinking of creating a new Team Project:
First off, Team Projects are team oriented, not individual oriented. Think of them as a container for resources for all the roles within a project (developer, tester, project manager, builder, change management, etc.). This includes development methodology, process guidance, a team sharepoint portal, a source control repository, a workitem repository, checkin policies, and reports. So if you find yourself wishing you could create a Team Project without all the extra "goo" (e.g. sharepoint portal, reports, etc.) that goes along with them, you might not be thinking about them in quite the right way...
Another point is that a Team Project is not the same entity as a solution or a source code project (e.g. a C# console application). A Team Project can contain multiple solutions and source code projects as well as much more (work items, reports, builds, etc.).
If your organization has only 1 application under development, the answer is easy; create a Team Project for your app and stick with it until you decide to follow a new development methodology. As you issue new releases, use iterations to track your milestones.
If your organization has multiple applications in development, it might be suitable to create 1 or many Team Projects depending on several factors.
- Do the products ship on the same schedule?
- Does each project follow the same development methodology?
- Can all the projects use the same work item types, check-in policies, or check-in notes?
- Are the applications logically related?
- How many source control versions and work items do you estimate the projects to contain?
There are also some excellent resources on MSDN. I'd start with Planning a Team Project. Once you've created the Team Project, you probably want to know how to configure your Team Project and how you can customize your Team Project.
Note that there is a big distinction between customization of existing projects and customizing new projects. The sky's the limit on customizing new projects, whereas customization of an existing project can certainly be done but is more limited. If you're into heavy customization, you may find yourself building a few Team Projects before you "get it right".