Organizing Team Projects

I recently answered a post in the MSDN Forums asking about best practices for organizing team projects (Organization of Team Projects). For my own benefit, I’m going to post it (and update it) here so I can find it more easily.

We've asked our patterns & practices team to develop content that addresses Team System best practices, but that will take some time to create as they need to evaluate many practices before they can promote one or more as best practices. In the interim, here are some things to consider, which shouldn't be misconstrued as representing official guidance.

Of course, you can only consider something to be a best practice within a given context. Below are some context variables that could sway a decision one way, or another.

  • Security - If you need to restrict access to the sub-projects within the overall development team, you may want to consider using separate team projects with one umbrella team project; however, the hierarchy is artificial since team projects exist as peers on the server.
  • Reuse - If a sub-project represents some piece of functionality you may use across multiple projects (a library, such as the enterprise library patterns & practices built), you may want to consider using separate team projects and use binary reuse of that common functionality across multiple projects.
  • Geography - If the independent development teams are working on sub-projects in relative autonomy, and they are geographically separated, you may want to consider separate Team Foundation Servers (despite the Team Foundation Server Proxy) to simplify the required infrastructure.
  • Process - If each sub-project is using a different process methodology, you may want to consider using separate team projects to allow each team to use a team project created from their chosen process template.
  • Size & Complexity - If your team is not comfortable working in the same team project due to the combined size or complexity of the various sub-projects, you may want to consider separate team projects.

That said, we built Team System using a single team project with a large development team dispersed around the world. Was that the best choice? Maybe, maybe not.


Comments (8)

  1. Rob Caron Blog Roundup:

    Organizing Team Projects

    Team System Wins Jolt Award

    Upgrading To Team Foundation…

  2. Jason D says:

    We do quarterly releases of a web site.  Do you recommend breaking each release out into a separate team project?  Another option is to use the Iteration work item field to differentiate between releases.  The security will be the same across releases, but there will be new spec documents and work items each release.

  3. RobCaron says:

    Jason – without knowing more about your circumstances, I would lean towards one team project.

  4. Bryan B says:

    Well I am happy I actually found something on this topic.  It seems this has been completely disregarded by Microsoft.  There has been so much talk on VSTS that would think it was the answer to every developer’s dream.  Having said that our company has a huge VSS database of hundreds of projects organized by line of business segments and technology architecture.  From what I gather from what you have said and from what I have attempted to make TFS do, it appears there is no way to organize these projects like we had in VSS.  I have migrate our VSS under one Team Project called "Migrated Projects".  But I am having trouble in VS 2003 to connect this up to TFS source control.  Do you know if this can even be done without creating a separate Team Project for every project in VSS.  This would be an absolute nightmare due to the number of projects we have.  Are we better off only using TFS for new projects?  If so then it seems our adoption of TFS will sadly be put off a long time.

  5. El Bruno says:

    Buenas, desde hace unos días estamos manteniendo una conversación interesante dentro de los foros de

  6. El Bruno says:

    Buenas, desde hace unos días estamos manteniendo una conversación interesante dentro de

Skip to main content