When should I use Areas in TFS instead of Team Projects in Team Foundation Server 2010

Well, it depends… If you are a small company that creates a finite number of internal projects then you will find it easier to create a single project for each of your products and have TFS do the heavy lifting with reporting, SharePoint sites and Version Control.

But what if you are not…

Paul Neumeyer – I asked Paul for a comment, and true to form he wrote an essay and with an evening with Sam Guckenheimer firing his blood it’s a good un’..

Eric Phan, Paul Neumeyer – After having long discussions with Eric and Paul I have added strategy for Migration to new process templates and of archiving old projects.

I ran into the problem of not being able to find a build called “Build” and had to search through 172 projects to find it. With Areas there would be substantially less projects to search. A good naming convention would also work Smile

Ognjen Bajic – Ognjen from Ekobit who make Team Companion made some comments that I found useful, which I have added.

Adam Cogan – Adam suggested I get our disagreement out in the open, improve the proposed solution description with some visual cues and move the Pros and Cons to the top. Last but not least, to plug out custom TFS template 🙂

Ewald Hofman gave me a couple of Cons, and maybe a few more soon. Ewald’s company, Avanade, currently uses Areas, but it looks like the manual management is getting too much and the project is getting cluttered.

Michael Fourie gave me some feedback which I have integrated.

What if you are likely to have hundreds of projects, possibly with a multitude of internal and external projects? You might have 1 project for a customer or 10. This is the situation that most consultancies find themselves in and thus they need a more sustainable and maintainable option. What I am advocating is that we should have 1 “Team Project” per customer, and use areas to create “sub projects” within that single “Team Project”.

What you describe is what we generally do internally and what we recommend. We make very heavy use of area path to categorize the work within a larger project.”
Brian Harry, Microsoft Technical Fellow & Product Unit Manager for Team Foundation Server

This post has an ulterior motive as I am having this debate with my boss, Adam Cogan, and we both decided that we wanted to find out what the community at large thinks of this approach to managing projects in TFS. Adam thinks this is a bad idea as it is not supported “out-of-the-box”, and I think that a lot of things are not supported “out-of-the-box” in TFS which never the less, are a good idea, including this one.

I’ve been a big advocate of using a single project per client for years because from experience a client will want to merge products or  have their name changed, a component form their existing project code base a client will want to ‘spin-off’ as a separate product with a different team without losing any work items or history, and there are always tasks that development teams can’t decide where to put when there are multiple, but related products in separate TFS projects.  All of that is easier with a  single project per client and using Areas.  Last night I spent an evening with Sam Guckenheimer and it is clear his vision of TFS was always targeted at a lot more that source control and a task tracking, TFS is a flexible application lifecycle management (ALM) system that if setup with Areas can streamline the decade+ lifecycle of interaction between developers and the guys with budget that is the reality we live in.
Dr Paul Neumeyer, Ph.D Parallel Processes, ScrumMaster and SSW Solution Architect

Using areas in existing team project instead of creating a new team project (a.k.a. “prefer small number of big team projects over large number of small team projects”) has been established best practice for long time. Microsoft works that way internally and they recommend everyone should. We use it internally and all of our partners have been thought to use it as well.
Ognjen Bajic, Visual Studio ALM MVP, Ekobit

We tend to use areas to segregate multiple projects in the same team project and it works well.”
Tiago Pascoal, Visual Studio ALM MVP

“In general, I believe this approach provides consistency [to multi-product engagements] and lowers the administration and maintenance costs. All good.”
Michael Fourie, Visual Studio ALM MVP

@MrHinsh BTW, I’m very much a fan of very large, if not huge, team projects in TFS. Just FYI 🙂 Use Areas & Iterations.”
Ed Blankenship, Visual Studio ALM MVP

I am proposing that SSW change from over 70 internal team projects:

  • SSW.CodeAuditor
  • SSW.SQLAuditor
  • SSW.SQLDeploy
  • etc

To 1 internal team project:

  • SSW.Agile5
    • CodeAuditor
    • SQLAuditor
    • SQLDeploy
    • etc

Note: The single Team Project called “SSW.Agile5” would contain all of our internal projects and consequently all of the Areas and Iteration move down one hierarchy to accommodate this. Where we would have had “SSWSprint 1” we now have “SSWSqlDeploySprint1” with “SqlDeploy” being our internal project. At the moment SSW has over 70 internal projects and more than 170 total projects in TFS.

This method has long term benefits that help to simplify the support model for companies that often have limited internal support time and many projects. But, there are implications as TFS does not provide this model “out-of-the-box”. These implications stretch across Areas, Iterations, Queries, Project Portal and Version Control.

Michael made a good comment, he said:

I agree with your approach, assuming that in a multi-product engagement with a client, they are happy to adopt the same process template across all products. If they are not, then it’ll either be easy to convince them or there is a valid reason for having a different template
Michael Fourie, Visual Studio ALM MVP

At SSW we have a standard SSW Agile process template that we use and this is applied across the board, to all of our projects. We even apply any changes to the core process template to all of our existing projects as well. If you have multiple projects for the same clients on multiple templates and you want to keep it that way, then this approach will not work for you. However, if you want to standardise as we have at SSW then this approach may benefit you as well.


  • You only have one project to upgrade when a process template changes – After going through an upgrade of over 170 project prior to the changes in the RC I can tell you that that many projects is no fun.
  • Standardises your Process Template – You will always have the same Process implementation across projects/products without exception
  • You get tighter control over the permissions – Yes, you can do this on a standard Team Project, but it gets a lot easier with practice.
  • You can “move” work items from one “product” to another – Have we not always wanted to do that.
  • You can rename your projects – Wahoo: everyone wants to do this, now you can.
  • One set of Reporting Services reports to manage – You set an area and iteration to run reports anyway, so you may as well set both.
  • Simplified Check-In Policies– There is only one set of check-in policies per client. This simplifies administration of policies.
  • Simplified Alerts – As alerts are applied across multiple projects this simplifies your alert rules as per client.
  • Process Template Upgrades – When a new process template is released, like “Agile6” we can create a “SSW.Agile6” project and move Area Projects ad-hock into it as we use them. This way we keep the history of the work items in tact and are able to properly upgrade to the new process template.
  • Archiving – We would be able to archive old unused projects by leaving them behind with history and source intact in the old “SSW.Agile5” project and then using the Project Collection splitting process to only keep active projects on TFS while keeping the database available if it is needed in the future.
  • Find all builds – You need to open a project to query builds, so you will be able to see all builds in one project.


All of these cons could be mitigated by a custom tool that helps automate creation of “Sub-projects” within Team Projects. This custom tool could create areas, Iteration, permissions, SharePoint and queries. It just does not exist yet 🙂

  • You need to configure the Areas and Iterations – This is just like you would do for Sprints/Iterations and for functional areas of your application, but with 1 extra level at the top of the tree.
  • You need to configure the permissions – This I guess is the main configuration point. It is possible to create the same permissions as a Team Project at this level, but that would be a bit of configuration work.
  • You may need to configure sub sites for SharePoint (depends on your requirement) – If you have two projects/products in the same Team Project then you will not see the burn down for each one out-of-the-box, but rather a cumulative for the Team Project. This is not really that much of a problem as you would have to configure your burndown graphs for your current iteration anyway.
    note: When you create a sub site to a TFS linked portal it will inherit the settings of its parent site 🙂 This is fantastic as it means that you can easily create sub sites and then set the Area and Iteration path in each of the reports to be the correct one.
  • Every team wants their own customization (via Ewald Hofman) – small teams of 2 persons against teams of 30 – or even outsourcing – need their own process, you cannot allow that because everybody gets the same work item types.
    note: Luckily at SSW this is not a problem as our template is standardised across all projects and customers.
  • Large list of builds (via Ewald Hofman) – As the build list in Team Explorer is just a flat list it can get very cluttered.
    note: I would mitigate this by removing any build that has not been run in over 30 days. The build template and workflow will still be available in version control, but it will clean the list.

Implications around Areas

Areas should be used for topological classification/isolation of work items. You can think of this as architecture areas, organisational areas or even the main features of your application. In our scenario there is an additional top level item that represents the Project / Product that we want to chop our Team Project into.

Figure: Creating a sub area to represent a product/project is easy.


Implications around Iterations

Iterations should be used for chronological classification/isolation of work items. This could include isolated time boxes, milestones or release timelines and really depends on the logical flow of your project or projects. Due to the new level in Area we need to add the same level to Iteration. This is primarily because it is unlikely that the sprints in each of your projects/products will start and end at the same time. This is just a reality of managing multiple projects.

Figure: Adding the same Area value to Iteration as the top level item adds flexibility to Iteration.

Sprint 1


Release 1Sprint 1


Sprint 1


Release 1Sprint 1

Implications around Queries

Queries are used to filter your work items based on a specified level of granularity. There are a number of queries that are built into a project created using the MSF Agile 5.0 template, but we now have multiple projects and it would be a pain to have to edit all of the work items every time we changed project, and that would only allow one team to work on one project at a time.

Figure: The Queries that are created in a normal MSF Agile 5.0 project do not quite suit our new needs.

In order for project contributors to be able to query based on their project we need a couple of things. The first thing I did was to create an “_Area Template” folder that has a copy of the project layout with all the queries setup to filter based on the “_Area Template” Area and the “_Sprint template” you can see in the Area and Iteration views.

Figure: The template is currently easily drag and drop, but you then need to edit the queries to point at the right Area and Iteration. This needs a tool.

I then created an “Areas” folder to hold all of the area specific queries. So, when you go to create a new TFS Sub-Project you just drag “_Area Template” while holding “Ctrl” and drop it onto “Areas”. There is a little setup here. That said I managed it in around 10 minutes which is not so bad, and I can imagine it being quite easy to build a tool to create these queries

Figure: These new queries can be configured in around 10 minutes, which includes setting up the Area and Iteration as well.

Version Control

What about your source code? Well, that is the easiest of the lot. Just create a sub folder for each of your projects/products.

Figure: Creating sub folders in source control is easy as “Right click | Create new folder”.





I think it is up to each company to make a call on how you want to configure your Team Projects and it depends completely on how many projects/products you are going to have for each customer including yourself.

If we decide to utilise this route it will require some configuration to get our 170+ projects into this format, and I will probably be writing some tools to help.


Now that I have explained this method, what do you think?

  • What other pros and cons can you see?
  • What do you think of this approach?
  • Will you be using it?
  • What tools would you like to support you?
  • Michael Ruminer

    You might have 1 project for a customer or 10. This is the situation that most consultancies find themselves in and thus they need a more sustainable and maintainable option. What I am advocating is that we should have 1 “Team Project” per customer, and use areas to create “sub projects” within that single “Team Project”.
    I agree in spirit but in execution for consulting I have found I have to go a different approach.

    I have not found the use of areas to work well for me when at scale. Working for a large consultancy we may do more than 1 project for a customer simultaneously with different delivery teams. Or multiple projects that need separation. All depends on how granular one defines customer. If the customer is Fidelity that likely won’t work. If the customer is defined as Fidelity – Bond – US Compliance group then maybe it works.

    With the new project collections in 2010 I’m leaning toward a Project collection per client project. At the end of the engagement the PC is turned over to the client to import into their environment.

    In the past it has gone so far as a TFS instance and individual domain per client project (under their licenses) so that we could turn over the entire virtual project infrastructure AD, TFS, WSS, SQL VMs at the end to the client.

  • Valerie

    New to TFS so excuse my ignorance. If we use Areas can we put common code in one area and branch it into another area? The use case is to be able to have common code that can be pulled into other projects. We don’t want to just pull in the dll, we want the code there. But we don’t plan to change the code in the project that uses it – only in the common area.

    I found this codeplex article that explains how we could do it but it goes across projects. One drawback is that the branch visualization doesn’t seem to work across projects. Could I instead use Areas?

  • Martin Hinshelwood

    Yes you can, but I would NEVER recommend this approach. Just place a copy of the DLL’s into a “ToolsMyOtherProject*.dll” folder in your target solution and reference them there.

    If you really need access to the source for debugging and reference then setup a “Symbols” server and use that.


  • Wes MacDonald

    Do you have an approach for managing the many builds that will exist for each project?

  • Martin Hinshelwood

    I agree that it would be difficult and it is not perfect. On the upside they are all in a flat list and would be easily discoverable 😉

    You would need a good naming convention if you were to have hundreds of builds in the same Porject.

    Maybe something like [Project].[Product]_[Branch].[BuildType]

  • Aaron

    This post has been very helpful! Can you add information on how to create sub sites for each area in SharePoint for for those of us who are not familiar with it?

    Do you have any suggestions on how to manage reports in this scenario? We are using the Scrum template and you can filter on reports by sprint, but as the area/iterations grow this filter list is going to become very large. I am curious to hear if you have modified the report to limit the sprints which show up?

  • Steve

    Great post, as we are trying to use and area to separate seperate smaller projects also. We also are doing Iteration 1 etc under each area. This seems to work well until you get to the Documents area in Team Explorer and under Excel Reports none of the defaults work anymore. The Product Backlog report still works but as far as the Iteration Backlog, Bugs etc. They are all broke now. I am now getting messages that the data in the Work Items are not valid. When I go back and create a Team Project under the not using my Areas and Iterations they work fine. Just something to think about when trying to go to this format.

  • Allen

    Great article! We are currently in the middle of transitioning from SourceSafe to TFS 2010 (yes, we’re years behind the curve!). Our company is small and I think it would benefit from structuring our products in Areas as you’ve discussed above. What I am debating right now is what process template to use. We have always had a very loosely defined agile process, but are moving toward using a more defined SCRUM methodology. With the release of the new Microsoft Visual Studio Scrum 1.0 template, do you still recommend starting with the MSF Agile 5.0 template? If so, can you tell me what the advantages/disadvantages would be?

  • Alfonso

    Great post Martin,
    I like the approach. However, I have the same concern as Aaron regarding the sub sites in SharePoint and how to manage reports in this scenario. I would like to hear if you came up with some particular solution or idea on how to accomplish this in an efficient manner. I know it all depends on your requirements, but any comments about it would be highly appreciated.

  • Patrick Magee

    I am currently consulting on a large eCommerce site that does most of its dev work off-shore in Java (the language not the country), and interacts with TFS using the TFS Everywhere plugin for Eclipse. The project is getting rather sick (over-budget, and late). We are not (currently) using workitems, so we are considering splitting out our rather large single project (which contains a number of sub-projects from different teams) to create separate team projects. The main motivation for this is to give us some clarity and standardisation across the various sub-projects. After reading this article I am wondering if it might be easier to get our devs to use workitems and areas and stick with the current monolithic structure.

    Has anyone any thoughts on this?

  • Richard Berg

    While this blog post is really old, my opinion hasn’t really changed: http://blogs.msdn.com/b/richardb/archive/2007/05/01/tfs-team-project-whitepaper.aspx

    There *are* some good reasons to split up team projects, but in practice, 90% of the reasons people have told me are no good 🙂

    If anything, there are fewer reasons today than ever. Look closely at Doug Neumann’s chart and you’ll see that some of the limitations that used to apply within a single team project no longer exist. For example, TFS 2010 allows fully hierarchical grouping (with permissions!) inside the Team Queries node of work item tracking.

  • Makoto Suzuki

    Thank you Martin for the very informative post. I’m in the middle of determining whether to use a single team project or multiple team projects.

    I’ve tested modifying the project portals and reports to support using different areas in a single project, and it does seem to work fine, except for the re-configuration of portal sites/reports/dashboards and changing permissions for each area, mirroring it to the portals as well. Though not too painful, it involves quite a bit of manual work and coordination.

    I’d like to see a tool that would handle this process – configuring the Team Project to support areas representing conceptual projects.

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

  • I have created an updated post for the new features of TFS 2012 http://blog.hinshelwood.com/one-team-project/

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

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

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

  • Tom Crag

    I have just moved all of our separate projects over to one single projects with each project being separated by a different area path. I feel that I may now be miss-using epics, as I have used epics to also separate the projects by having one epic per project. As the area path serves this purpose should I just use epics the same way as I would use them with multiple VSTS projects? If i did this, is there any down side to just relying on area path to distinguish between projects on a single project VSTS set up? What would the most appropriate use of epics be in a single project VSTS set up? I would greatly appreciate any advise and examples in regards to this.

    • Yes, you should use them just as you would if you had one project in your Team Project

      • Tom Crag

        Thanks for your response, that’s helped out allot.