Working within a single Team Project with Team Foundation Server 2012



Working within a single Team Project with Team Foundation Server 2012 provides a lot of benefits. There are however many design consideration for working within a single team project and we need to consider all of the complexities that is entails.

One of the customers that I work with has over 200 departments in their organisation that are currently using TFS and each one of those supports one or more teams building multiple products in a single team project. They do not give any of those divisions “Project Administrator” on their Team Projects and in itself sounds like a management nightmare. Why? Well that means that ANY security change needs to go through a central administrator. In order to support this type of situation we need to create some workflow for making sure that everything is setup correctly and some automation so that we can build out the correct permissions without needing direct access. But before we do that we need to look at all of the angles and design our implementation to take advantage of the features in Team Foundation Server 2012.

The TfPlugable Team is part of the TfsExtension Team Project
Figure: The TfPlugable Team is part of the TfsExtension Team Project

Unfortunately the implementation of Team Project is a little flawed as it imposed some technical restrictions that are difficult to live with and if you look at the top items on the Team Foundation Server User Voice site you can begin to get a handle on the issues. Even worse, the inability to rename your Team Project is the least of your worries; You can query across Team Project but that’s not the default; You can’t load cross Team Project queries in Excel; You can’t move a work item created in one Team Project to another.

Ultimately we should always have been working in a single Team Project even if we did not know that we were supposed to.

What you describe [single team project] 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

Design considerations for Working within a single Team Project with TFS 2012

Because Team Foundation Server is a group of tightly coupled but flexible services it does not force you into any one way of working like many other tools. So we do need to think about how we are organising our Source Control, Areas, Iterations and Teams to understand how we might be impacted across the board and what our automation workflows are. In our deliberations we have three main entities that we need to cater for:

  • Team – This automatically creates our Security Group that we will be using and has an Administrator is set for that group
  • Product – When you create a product you will likely need both a Source Control location for that Product to reside and an Area to contain the related work items. You can break your product down into components inside that Area and you may have branches under the Source Control folder but the layout and organisation should be up to the product owners and the team.
  • Project – A Project is something time limited so lends itself to an Iteration within TFS but you would not prescribe the cadence. Your Project many be waterfall or Scrum or Kanban and it should not matter.

There many be other things like Work Stream or Cost Code or other flat categorisation elements that you might want to use in your single Team Project. These can easily exist as drop-down-lists on the work items that exist in our requirement work item and don’t necessarily impact the workflows described above.

“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, Product Owner of Team Companion at Ekobit

Note You may want to have Teams own projects. If you have many projects and your teams own more than one at ay time you can use Teams without areas but instead of having a list of “Teams” you create a list of Projects and define which Teams own which projects in the Team configuration.

Team in a single Team Project

In Team Foundation Server 2012 everything within a Team Project revolves around a new feature called Team. A Team is ultimately a security group with a bunch of meta data and features hanging from it (Yes..unlike a Team Project you can rename a Team). In the agile world a “Team” represents a long running tight group of individuals that operate more like a sports team but building software. If you are not an agile team, or in that half way phase of trying to get there, then you might also think of “Team” as something more akin to “Project”. In that scenario you have a time limited group of individuals that operate either full or part time together only for the duration of said “Project”. While the latter would reduce the effectiveness of the Team and would thus be considered a dysfunction it can often be a reality of that awkward transition towards agility.

Adding teams working in a single Team Project
Figure: Adding teams working in a single Team Project

In either of these cases you can use Team as the thing that you create instead of Team Project. This Team gives you the bucket of compartmentalisation of work items while allowing those teams to interact in a tightly integrated manor as needed. You also gain the ability to move work items between teams and query cross team with ease. If you are working on a large software project you might have many teams on the same cadence and while you want them to have their own space they still need to integrate and report things together. Or you might have multiple cadences across multiple products and only teams working on the same product work in the same cadence. The Team feature gives you the flexibility to choose you own way and adapt as you grow.

Product in a single Team Project

Product is a thing that you version, create instances of, and then deploy to production. A version of this entity is what is promoted through your release process although you may need to break it down into components if it is really big. Some of your Products will be built in an agile fashion and release at least every 30 days while other will have longer iterations and be delivered less regularly. We need to come up with some way to wrap all of our Products regardless of the things that may be different between them. This interface will allow us to control creation and security by following a pattern that we can automate.

Area as Product when working in a single Team Project
Figure: Area as Product when working in a single Team Project

Considerations for your Product hierarchy:

  • Area Hierarchy – Within a Product we may have components or trees of components. Area support roughly 254 nodes per level and can be 11 deep so there are limitations to consider. You will always see all of the nodes and you can control security at each and every level.
  • Version Control Hierarchy – Each of our Products are going to have source code and other associated files. We need somewhere to keep them in isolation now that we don’t have Team Project so that we can control permissions and isolation.

Note If we maintain the level at which Product exists in both Area hierarchy and in Version Control then we can easily automate against it.

Note The same rules apply and you can use the same physical organisation as Project of Projects with Team Foundation Server 2010.

Project in a single Team Project

Project is that time limited group of deliverables that results in a new release of one or more Products. The Project may contain many releases or it may be one. A Product may have many Projects or even just one that contains many releases. We need a model that supports whatever our teams need and that is reflected in Iteration Path.

Iteration as Project cadence when working in a single Team Project
Figure: Iteration as Project cadence when working in a single Team Project

Considerations for Project hierarchy:

  • Iteration Hierarchy – Creating a hierarchy in Iteration gives us the ability to have single or multiple strands of time allocation. It can be split by Team or Product or Project and each of those things can have their own cadence. That cadence should not be determined arbitrarily by the process overlords, but instead we can allow each unit to determine their own cadence.


While I can’t hope to provide a method of using Team Foundation Server 2012 and its features that work for everyone I am trying to create a versatile wrapper for any sort of work that is done within a Team Project. Ideally you would have only a single Team Project within your Team Project Collection and using Teams, Area Hierarchy and Iteration Hierarch we can map to but not into Teams, Products and Projects. The hope is that this wrapper described in the design guidelines above can allow you to automate against the TFS API’s and thus minimise your administration overhead while providing that versatility. There is an awesome post on backlog grooming that shows you how to configure more advanced team organisation in Team Foundation Server with Teams and there are plenty of other options.

If you are using Team Foundation Server already then there may be a lot of work that needs to be done to reorganise your existing work before you start as well as implementing your new and specific workflows based on the generic implementation above. This is however the only way for an enterprise, or really any organisation with more than one team, to take advantage of the new Agile Project Planning features of Visual Studio Team Foundation Server 2012.

It can however be a lot of work and the great god Murphy can strike at any time. Plan carefully and make deliberate and tested changes to TFS and your structure to support this.

Upcoming Training Opportunities

These are the next five classes we have, and you can check out our full public schedule of classes.

Live Virtual Applying Professional Scrum Minecraft on  12th December 2022
Virtual Beginner 0
12 - 15 Dec, 2022
14:00-17:30 GMT
Live Virtual Applying Professional Scrum Online in Minecraft on 30th January 2023
Virtual Beginner 12
30 Jan - 2 Feb, 2023
09:30-13:00 GMT

We can deliver any of our courses as private in-house training over Microsoft Teams & Mural. We also recommend training based on your accountabilities or role, you can go directly to recommended courses for Scrum MastersProduct OwnersDevelopers and Agile Leaders.

Create a conversation around this article

Share on Facebook
Share on Twitter
Share on Linkdin

Related Courses

No items found

Read more

Martin Hinshelwood (He/Him)
To my understanding there is a frustrating misunderstanding of reality when one thinks that the Product Owner can reject a single story at the Sprint Review. This is the fallacy of the rejected backlog item.
Martin Hinshelwood (He/Him)
There is no such thing as an Agile Transformation, Digital Transformation, DevOps Transformation, or any of the Whatever Transformation that you can think of or have been sold. You can’t buy agility, and you certainly can’t install it. There is no end state, no optimal outcome, No best practices. We …
Martin Hinshelwood (He/Him)
In light of the new normal and the last 20 years of technological progress, we need to re-define co-location as we no longer need to be in the same room as each other to get the 80% of communication that is non-verbal. If we are participating in an online event, …
Martin Hinshelwood (He/Him)
Gathering the metrics for Evidence-based Management in software organisations can be a strenuous task and I have a number of customers that are fretting on what to collect and from where. Here I try to create an understanding of the ‘what’ that we need to collect.


We believe that every company deserves high quality software delivered on a regular cadence that meets its customers needs. Our goal is to help you reduce your cycle time, improve your time to market, and minimise any organisational friction in achieving your goals.

naked Agility Limited is a professional company that offers training, coaching, mentoring, and facilitation to help people and teams evolve, integrate, and continuously improve.

We recognise the positive impact that a happy AND motivated workforce, that has purpose, has on client experience. We help change mindsets towards a people-first culture where everyone encourages others to learn and grow. The resulting divergent thinking leads to many different ideas and opportunities for the success of the organisation.