Team Development with Visual Studio Team Foundation Server

How should I organize my team projects?
Team projects are intended to represent the largest unit of work possible in your
organization. Most often this will be a product under development.
Consider one of the following strategies for managing team projects:
• Create one project per application.
• Create one project per release.
Create one project per application
If you want to carry forward not only source code but also work items and other TFS
assets between releases, consider using one project per application. When you use a
single project for multiple versions of the application, all of the TFS assets are carried
forward automatically for you for the next release. When you are ready to release a new
version of your application, you can create a branch within the project to represent the
release and isolate that code.
The following are reasons not to use one project per application:
• Releases in parallel are forced to share work item schemas, check in policies, and
process guidance.
• Reporting is more difficult; because reports default to the entire project, you must add
filtering by release.
• If you have hundreds of applications, each in its own project, you will run up against
TFS performance and scale limits.
• You will accumulate ‘baggage’ over multiple releases. The easiest way to eliminate
this baggage is to create a new team project and then branch code you want to carry
forward into that project.
Create one project per release
If you want each release to start fresh without carrying forward work items and other TFS
assets, consider using one project per release. When you use a new project for each
release, you can modify work item schemas, workflow, check-in policies, and other
assets without impacting the old release. This can be especially useful if the old release
will be maintained by a separate team, such as a sustained engineering team who may
have a different process and workflow than your main development team.
The following are reasons not to use one project per release:
• While it is very easy to move the source code from one project to another, it is
difficult to move work items and other TFS assets from one project to another. Work
items can only be copied one at a time to another project, if you want to copy sets of
work items you’ll need to write your own utility.
• If you have hundreds of applications and releases, each in its own project, you’ll hit
Team Foundation Server performance and scale limits.
Keep the following considerations in mind when choosing your strategy: