Project of Projects with team Foundation Server 2010

It is pretty much accepted that you should use Areas instead of having many small Team Projects when you are using Team Foundation Server 2010. I have implemented this scenario many times and this is the current iteration of layout and considerations.

If like me you work with many customers you will find that you get into a grove for how to set these things up to make them as easily understandable for everyone, while giving the best functionality. The trick is in making it as intuitive as possible for both you and the developers that need to work with it.

There are five main places where you need to have the Product or Project name in prominence of any other value.

  • Area
  • Iteration
  • Source Code
  • Work Item Queries
  • Build

Once you decide how you are doing this in each of these places you need to keep to it religiously. Evan if you have one source code file to keep, make sure it is in the right place. This makes your developers and others working with the format familiar with where everything should go, as well as building up mussel memory. This prevents the neat system degenerating into a nasty mess.


Areas are traditionally used to separate out parts of your product / project so that you can see how much effort has gone into each.

Figure: The top level areas are for reporting and work item separation

There are massive advantages of using this method. You can:

  • move work from one project to another
  • rename a project / product

It is far more likely that a project or product gets renamed than a department.

Tip: If you have many projects, over 100, you should consider categorising them here, but make sure that the actual project name always sits at the same level so you know which is which.

Figure: Always keep things that are the same at the same level

Note: You may use these categories only at the Area/Iteration level to make it easier to select on drop down lists. You may not want to use them everywhere. On the other hand, for consistency it would be better to.


Iterations are usually used to some sort of time based consideration. Here I am splitting into Iterations with periodic releases.

Figure: Each product needs to be able to have its own cadence

The ability to have each project run at its own pace and to enable them to have their own release schedule is often of paramount importance and you don’t want to fix your 100+ projects to all be released on the same date.

Source Code

Having a good structure for your source even if you are not branching or having multiple products under the same structure is always a good idea.

Figure: Separate out your products source

You need to think about both your branches as well as the structure of your source. All your code should be under “Source” and everything you need to build your solution including Build Scripts and 3rd party tools should be under your “Main” (branch) folder. This should them be branched by “Quality”, “Release” or both to get the most out of your branching structure.

The important thing is to make sure you branch (or be able to branch) everything you need to build, test and deploy your application to an environment. That environment may be development, test or even production, but I can’t stress the importance of having everything your need.

Note: You usually will not be able to install custom software on your build server. Store any *.dll’s or *.exe’s that you need under the “ToolsTool1” folder.

Note: Consult the Branching Guidance for Team Foundation Server 2010 for more on branching

Figure: Adding category may be a necessary evil

Even if you have to have a couple of categories called “Default”, it is better than not knowing the difference between a folder, Product and Branch.

Work Item Queries

Queries are used to load lists of Work Items out of TFS so you can see what work you have. This means that you want to also separate queries out by Product / project to make it easier to find the correct data for a particular product.

Figure: Again you have the same first level structure

Having Folders also in Work Item Tracking we do the same thing. We put all the queries under a folder named for the Product / Project and change each query to have “AreaPath=[TeamProject][ProductX]” in the query instead of the standard “Project=@Project”.

Tip: Don’t have a folder with new queries for each iteration. Instead have a single “Current” folder that has queries that point to the current iteration. Just change the queries as you move from one iteration to another.

Tip: You can ctrl+drag the “Product1” folder to create your “Product2” folder.


You may have many builds both for individual products but also for different quality’s. This can be further complicated by having some builds that action “Gated Check-In” and others that are specifically for “Release”, “Test” or another purpose.

Figure: There are no folders, yet, for the builds so you need a good naming convention

Its a pity that there are no folders under builds, some way to categorise would be nice. In lue of that at the moment you can use a functional naming convention that at least allows you to find what you want.


It is really easy to both achieve and to stick to this format if you take the time to do it. Unless you have 1000+ builds or 100+ Products you are unlikely

run into any issues. Even then there are things you can do to mitigate the issues and I have describes some of them above.

Let me know if you can think of any other things to make this easier.

  • Ed Blankenship

    I like to call them “product families.” You may have multiple products in a product family be on the same release/iteration cycle so you would want to them to all use the same Iteration Paths.

    It’s really about figuring out the release cadence and then grouping products in their relevant product families. Definitely more of an art instead of a science.

  • Alan Low

    I like the ideas mentioned within this article, but I have a question about what to do in situations where you have a main product and addtional products that have references to c# library projects in the main product?

    • Anything that is not part of your solution should be treated as a third-party product. Link to version’ed assemblies that have passed whatever release management criteria you have.

      note: Never, ever share code between projects… There was a reason that the TFS team did not implement Sharing from VSS and it was not technical.

      • Anonymous

        Why do you say “never share code between projects?”

        • Mainly because it is always a bad idea 🙂

          I am not talking about using “linked files” between projects in VS, but instead sharping code rather than DLL’s between the VS Solutions that represent high level deliverable.
          i.e. “Anything that is not part of your solution should be treated as a third-party product. “

          • Anonymous

            That clarification helps. For a moment, I thought you were opposed to code reuse of any kind through shared libraries. That did not make sense.   So it is the sharing for code at the main application level to which you have objection. But you still did not explain why you object to that. Only to reiterate that “it is always a bad idea.”   Can you give me a scenario to illustrate the harm that comes from sharing code in this way?

          • I very much in favour of code reuse. 

            Bottom line: Code Sharing is BAD and leads to code duplication and not code reuse. It is the method of code reuse that is the point of contention. You should be dependant only on the “output” of the shared library and not on the source files. As to scenarios, I can think of no scenarios where it is advisable to share source files between products/solutions.The reason being is that things can get complicated an unwieldy very quickly. What if you have move than one dependant to a shared library that all make changed to the same code and they alternately break each other. The only way around that is to start branching your common code into the other projects which now adds a level of complexity and integration that will never get handled in the long run and you will end up with three or more versions of the same code base over time.What you should do is have a single core component that is changed and build to produce output. This output can then be pulled on demand into the other projects that depend on those changes or not. This results in fewer breakages, better architecture and less technical debt. You can even introduce NuGet into the equation using either a hosted on in-house server to publish your common component and notify each of the consumers when a new version is available.

          • Anonymous

            Thanks for the detailed scenario, Martin. I have shared code libraries between two applications before and it was not so bad as you describe. Yes, occasionally, we might make an improvement to serve one solution, and that would break the other solution. But our CI builds found that pretty quickly. Then the affected team could adjust their software to utilize the newer, better version.   The alternative would be for the other team to take a frozen copy of our DLL and periodically update it on a schedule that fits their convenience. Then, if we had made breaking changes, they could deal with them at the time of their choice instead of being forced to deal with it when we made the breaking change. 

             It does not seem to me that one approach is inherently right and the other wrong. Rather, I see tradeoffs. By sharing source code, we were forcing the other team to integrate to our changes as quickly as possible. If they used DLLs, then they might forget or neglect to update all external dependencies and deploy software with older versions of software with known defects, even though our latest version was up-to-date.  Yet I can see the value in the approach you advocate. To me it depends on the context.   My context is an enterprise application with two solutions that should be kept integrated with the very latest stuff when they deploy. Any annoyance they encounter during changes is a sign of early integration and well worth it. But I can certainly imagine scenarios when I might adopt another approach.  I will try to keep an open mind on this in the future to ensure that we make a deliberate choice one way or the other, for a good reason, rather than just assuming that one way is always the best. But that is as far as I am ready to go at this time. I am not yet ready to say I will NEVER share source code libraries among solutions.

            Oh, and I almost forgot to thank you for this post. It is one of the most valuable posts I have seen for a TFS team.

  • Dan McQ

    Brian Harry posted this link recently about build folders:

  • Dennis

    Ever tried printing any of your posts? It doesn’t not look too good, any chance of a fix?

    • What is this printing thing you are talking about? 🙂
      This should now be fixed… let me know if it is still broken.

    • This should now be fixed with the move to WordPress… let me know if there are still problems.

  • stian.danielsen

    Hi there Martin and thanks for your insightful post!

    In my company we have 10+ different products and developer teams and are now reevaluating how to best organize it all in TFS.

    Here is a question for you:
    We would like to use a single Team Project and separate the products using Areas. In some cases, several teams do development on the same product.
    How would you resolve this so that each teams work items don’t get mixed up with other teams working on the same product (each team has different releases/iterations)?

    This is the structure we initially go for in Areas:

    …considering multiple teams working on the same product we could maybe structure it like this:

    What do you think of that?

    Alternatively, we could lump everything into and then separate stuff using Iterations…so the Iterations structure would look like this:

    Which solution would you suggest?

    • Well it depends 🙂 If all of your teams are on the same cadence then use AreaProductTeam, but if they are on different cadences you should use IterationProductReleaseTeamSprint or 
      Team ReleaseSprint. In DEV11 this problem goes away as it has the idea of teams built in. Ho, another option would be to put a drop-down-list on your PBI for team…

      All options suck… fixed in dev11 

      • stian.danielsen

        Thanks a lot, Martin!

        I think we are leaning towards a product-focused structure, avoiding putting in TeamName.

        So, the areas will look like:

        …and the iterations will look like:

        Feature would be a new version, maintenance, a new gui etc.

        I think this setup will work very well for us – with the benefits of having all within the same Team Project.

        With the upcoming TFS 11 in mind, would you still advocate keeping all in the same Team Project?

        • I still advocate for a Project of Projects with the upcoming TFS11, Dev11 and TFS Service (TFS Azure)


    “Instead have a single “Current” folder that has queries that point to the current iteration. Just change the queries as you move from one iteration to another.”

    What exactly does this mean? As soon I move on to the next iteration, the Current Folder holds all items assigned to the Iteration “cutrrent”, what to do then?  Rename the iteration and reassign all items as well? Should it be this work intensive…? What is best practice here?

    • In order to not have to change all of the queries in “Current” then you should create the following:

      ..Release 1CurrentSprint 1
      ..Release 1Sprint 2
      ..Release 1Sprint n

      Change all of your queries to point to “Under” “..Release 1Current” which will automatically include “Sprint 1”. 
      When you move to “Sprint 2” just move “Sprint 1” out of “Current” and move “Sprint 2” under “Current”.


  • John Balch

    I am working with a big company that develops some internal applications, supports many external applications. We are currently starting to use TFS 2010, each department or entity has its own applications of both internal and external. Each entity can create its own team projects and basically setup anyway they would like. I am trying to find what would work best for the setting up of team projects as whether 1 is best for all projects or 1 for internal, and 1 for external supported applications. Mostly the external applications do not require development, but we have to schedule upgrades, testing of their changes, UAT, etc. So I would like to be able to provide the best solution on how to best do this. My guess after reading everything I can find, would be to have a team project for all external facing applications even the ones we host here on premises and use ‘Areas’ to separate each application. Then another team project for internal applications and use ‘Areas’ to separate those out. Any assistance would be greatly appreciated.

    • Lumping your groups together sounds like a double edged sword! I would rather suggest that you create one team project per Group/Department and split the areas out.

      Example 1: “TeamProject1InternalProjectA” and  “TeamProject1ExternalProjectB”
      Example 2: “TeamProject1ProjectA-I” and 

       The only value in having Internal and External as separate entities is if you want to more easily report on “All External” or query based on that.Example 3: “TeamProject1ProjectA” but create a “Project Info” work item type that associates metadata with your project and has a drop-down-list for “Internal/External”

      • John Balch

        Hi Martin,
        Thank you for such a fast response. I agree with your statements. Currently before I started here, a month ago, the department i work in has a 3 or Team projects, 1 for applications, 1 for reports, 1 for interfaces, etc. I just need to have some concrete data when i go to my boss to suggest just 1 team project is best.
        Thank you again, and I am sure I will need to reach out to you again..

  • Pingback: Visual Studio ALM with Team Foundation Server, Visual Studio & Scrum | One Team Project()

  • I have created an updated post for TFS 2012 that addresses the addition of the “Team” entity.

  • Pingback: One Team Project Collection to rule them all–Consolidating Team Projects - Visual Studio ALM()

  • Pingback: Why should I consider merging my Team Projects in TFS 2010 | Vincent Labatut's Quest()

  • Pingback: Buying into the Team concept of TFS 2012 | Urban Turtle's blog()

  • Pingback: Why You Should Use a Single TFS Team Project | Imaginet Blog()

  • Pingback: Why You Should Use a Single TFS Team Project - Imaginet()

  • Johnny Boldt

    Q: Does a single team project still make sense with TFS2015, or has new functionality made it unnecessary?