This project is read-only.

How to choose one team project vs multiple team projects

- J.D. Meier, Jason Taylor, Alex Mackman, Prashant Bansode

To plan your project structure, evaluate common project organization strategies and choose the one that best fits your organization’s size, server constraints, and process workflow. Projects are intended to represent the largest unit of work possible in your organization. You should preferably choose a single project versus creating multiple projects. Use multiple projects when there is strong reason for doing so; for example, the team changes, or there is significant change from one release to another and you do not want to carry the unwanted work items (bugs, etc.) forward, or there is change in the process template, and so on.

The main advantages of creating a single project versus multiple projects are that it simplifies the moving of requirements, features, scenarios, and bugs between releases.

The most important decision points are:
  • Do you want to maintain work items and other assets from release to release? If so, choose to keep all releases in the same project.
  • Do you want to create a new process and work item structure from scratch when you move to a new release? If so, choose to create a new project for each release.

Common project structures include:
  • One project per application. Use a single project to contain all versions of your application. Create one branch per release within that project.
    • Reasons to use this structure: Makes it easy to carry forward code, work items and other assets.
    • Reasons not to use this structure:
      • Releases in parallel are forced to share work items’ schema, 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 may run up against TFS scalability limits.
      • You will accumulate ‘baggage’ over multiple releases. The easiest way to clean this up is to create a new project and branch the code you want to carry forward into that project.
  • One project per release. Create a new project for each version of your application.
    • Reasons to use this structure:
      • It works well if you want to start with a clean project after every release.
      • The old project can be used for maintenance and handed off to a separate sustained engineering team.
      • It is easy to move source from one project to another.
    • Reasons not to use this structure:
      • It is difficult to move work items and TFS assets from one project to another. Work items can only be copied one at a time to another project. If you want to move sets of items, you will need to do so manually or write your own utility.
      • If you are managing hundreds of projects, you may run up against TFS scalability limits.

Keep the following considerations in mind when choosing your strategy:
  • Choose a structure you can live with in the long term because restructuring existing team projects can be difficult.
  • Source can be easily shared among team projects:
    • Branch source from one project to another.
    • Map source from another project into your workspace.
  • Team Foundation Server can scale to ~500 projects using the Microsoft Solution Framework (MSF) for Agile Software Development Process (MS Agile) or 250 projects using the MSF CMMI process. If you create your own process or customize an existing process, keep in mind that the work item schema has the greatest impact on server scalability. A complex schema will result in a server capable of supporting fewer projects.

Additional Resources

Last edited Jul 18, 2007 at 12:07 AM by jtaylorsi, version 5


RichardBerg May 3, 2007 at 9:29 PM 
Don't miss Doug's new article: