Subscribe to our blog by signing up for the naked Agility newsletter, or by subscribing to the RSS feed.

One Team Project to rule them all

imageI have talked often of the idea of a Project of Projects in Team Foundation Server and with the new feature in Visual Studio 2012 Team Foundation Server I though it would make sense to revisit. I will talk a little of the idea of the Master or Hierarchical Backlogs using the new Agile Planning tools and I always find an example help with understanding so I will be using a recent engagement as a base. But first lets dispel a few myths.

  • Team Project ≠ Team
  • Team Project ≠ Project
  • Team Project ≠ Product
  • Team Project = WTF?

You might think that it has been unfortunately named, but the Visual Studio ALM tooling has been designed to have a low barrier to entry and as such the happy path is:

  • Team Project = Team
  • Team Project = Project

Have I confused you yet?

Well, for the single, or small group of developers the common and easy path is to create a new Team Project for each project and they will only ever have one team. So this is the way that it is out-of-the-box and it serves its purpose.

One Team Project to rule them all

The rest of us live in a more complicated world of multiple teams, multiple projects and multiple priorities. To achieve this we need to think about the following things in Team Foundation Server:

  • Teams (can be mapped to Area or to a Work Item Field Definition)
  • Areas (Tree)
  • Iteration (Tree)
  • Source Code  (has folders)
  • Work Item Queries (has folders)
  • Build

No matter what our configuration and requirements we can use a single Team Project. There are however a number of circumstances where you will not be able to do this:

  • A large consultancy

    If you are in a large consultancy with 1000+ customers then it makes more sense to use a  one Team Project per customer model so as to avoid confusion and scaling issues. Don’t think just because you are a consultancy that you need to use this model. Think carefully about your choice…

  • An organisation with 100’s of Teams

    If you are a single organisation that has 100’s of teams than you might also run into limitation of scale. I would in this case recommend that you have one Team Project per Department or Division depending on their scale and organisation.

  In these cases there are two limitation that need to be considered carefully. You can only have 254 areas per level and there is a soft limit of about 300 Team Projects per Team Project Collection. 

If neither of these apply (or you are at the Customer, Department or Division level within an organisation within which it does) then you can achieve a single Team Project.

One Team Project to find them

So, what has changed? Well with the advent of the idea and the technical implementation of Team in Visual Studio 2012 Team Foundation Service we can take advantage of the new constructs and reduce our complexity while simultaneously increase our features.

I do however have a reality check for those of you that want to use the new tools but work within a traditionally run organisation.

More than 34% of companies are now doing agile
Figure: More than 34% of companies are now doing agile

They are called the “Agile Planning” tools for a reason. They are exclusively targeted at the ~34% of the industry that are working in an Agile manor and that are 3 times more  likely to succeed than a traditionally run project. They are also aimed at the 30% that don’t really know what the want as an easy adoption path.

Agile projects are 3 times more likely to be successful
Figure: Agile projects are 3 times more likely to be successful

Does this mean that those of you can’t use the Agile Planning tools? Hell no! It just means that you are not in the happy path so make the most of them that you can.

One Team Project to bring them all

In a recent engagement my customer needed some rather specific things to be possible but also wanted to take advantage of the new Agile Planning features. They wanted to pull together all of the Teams and individuals from the Business all the way through the Development Teams to Infrastructure. To achieve that we identified a few must haves:

  • Must be able to see an ordered backlog per team
  • Must be able to see an ordered backlog per department/customer
  • Must be able to see what product and product area each work item is assigned to

In order to achieve this all I need to customise is to add a single new field to the Product Backlog Item. Is we add a “[mycustomer].Customer” field to the PBI and make it a drop-down-list of all of the existing customers

Figure: Adding a field to store the external customer

I can then create a query for each of the customers to show the backlog and allow anyone with permission to view that backlog.

Figure: A Query showing an external customers backlog

If I can query it I can then export to excel and reorder it just like we did when connecting to TFS 2010.

Figure: Reordering the backlog in Excel

So with a single added field we have enabled not only querying and ordering of data associated with a customer, but we also made the field reportable as a dimension in the data warehouse and cube.

Awesome and easy…

Now all we need to add is two teams in the new Agile Planning tools in addition to the default and configure them to only show their own backlog based on the Area Path (or we can configure it to use a Team drop-down).

The point is that we can support most, if not all configurations as long as you are willing to change the way that you work a little. Hopefully not much, but there is always change in adopting a new tool. Although we don’t want our tools to prescribe our workflow, we may actually want to change the way that we work to take advantage of cool things that we just had no access to before.

And in the Process Template bind them

220px-GollumThe key to a successful Team Foundation Server deployment is in the Process Template that is chosen to be the base moving forward. I always start with the Visual Studio Scrum template as a base as it has the most compatible workflow and terminology to the way we tend to speak and discuss about work.

Remember that whatever process template that you pick it is but a starting point for building your own process on top of. Don’t be afraid to customise, just don’t go nuts… no one likes a frankin-template…


Not only is larger Team Projects the recommendation of almost all of the experts in the field, it is also the recommendation and expectation of the product team for mature teams and organisations using Team Foundation Server.

How are Team Projects used at your organisation?

  • Pingback: Visual Studio 2012 RTM available & installed - Visual Studio ALM with Team Foundation Server, Visual Studio & Scrum()

  • Pingback: When should I use Areas in TFS instead of Team Projects in Team Foundation Server 2010 - Visual Studio ALM()

  • Pingback: Project of Projects with team Foundation Server 2010 - Visual Studio ALM from Martin Hinshelwood()

  • Gavin Stevens

    I think it’s important to recognize and enforce these concepts:
    Teams (can be mapped to Area or to a Work Item Field Definition)
    Areas (Tree)
    Iteration (Tree)
    Source Code  (has folders)
    Work Item Queries (has folders)

    Iteration -> Time
    Area -> Space

    The Iteration / Area structure should describe your source control structure as to provide a natural implementation of the Work over Time.
    Too many companies may fall into the trap of customization and end up changing Iteration path to an iteration which has nothing to do with the underlying source control, or the releases they are trying to deliver, making the overall system much more complex to manage. 

    A companies focus should be on iterations of a release, which is actually describing the underlying source code branch, not iterations of a team or other functional unit.

    Area path too, in maturity, seems to “fragment” where it may have started out as a structural description of the underlying source.  Later in time area naturally starts to fragment as you try to store too much information in this single hierarchy.  Soon area path can become, component based, feature based, and functional all at the same time.

    Failure to follow a strict structure of iteration and area can causes a twist in the reality of “what source/where is supposed to change in this iteration / area ?”  The Iteration / Area should describe the underlying source code which is the object of change for this iteration.

    Make sure to stick to these basic principles of TFS’s architecture. 
    Iteration = Releases over time, broken down into as many time boxes as you want.
    Area = The thing changing over time, again broken down into as deep a depth as you want, but try to keep area describing a single dimension of data like (Structural, Functional, Feature Based) choose ONE,  add new fields which bind to global lists to your work items for the others.

    In the end TFS is simply a database of a few related work item types.  The entire utility of which to track change over time in a complex system.  Make sure you keep the dimensions TFS provides aligned with they way you branch and build your source code also.  

    In a complex, mature system, the basic fundamentals of storing source control, and tracking change in it over time cannot be ignored.

    • FireofAries

      Hi Im not sure I understand the concept of project hierarchy in TFS very well. In my company we have a finite amount of products for internal use, a few common database and components, all which are modified through fixes/production support. We follow a waterfall dev process, not sprints like scrum. We have less than 50 developers. Could you give me some advice on what would be an optimum way to organize tfs? like Product1 with feature 1-2-3-n, fix1-2-3-n ? I don’t understand the concept of team in tfs either…

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

  • Aaron Corcoran

    With the concept of Teams, does one actually have to modify the queries any longer? As it seems in TFS 2012, each team has its own unique set of queries. Just getting started with the concept of teams mapped to areas, but it seems this reduces the management of queries (that was listed in the 2010 post). I may be missing a step, as I get the areas/iterations then assigning teams -> areas (for the one master backlog)…at least I think I do =) But wasn’t sure about the queries.
    Secondly, with the one master backlog, is it true to say that you wouldn’t be managing the overall release from the root project, each project would be managed separately. E.g. your not going to be assigning items from the master backlog to individual area sprints…that would be done through each ‘team’s area’.

    • You are correct that you get queries, both “team” and “my” for each “Team” that you create within a Team Project. You also get Alerts per team. This is one of the biggest advantages of moving to TFS 2012 from the perspective of the management of work.

      To you second point… well it depends. You may indeed want a Master Backlog with some sort of hierarchy if you have many teams (10’s) working on the same or related products. That way you could have a single vision for large rocks that are disseminated between teams…

      • Aaron Corcoran

        Thanks for the reply. I’m just starting to get my feet wet with 2012 and like the team mapped to area approach. Looks like it is a perfect fit for most organizations. Manage the master backlog, assign it to team/areas, then each team can prioritize their own sub backlog and work the sprints accordingly.
        One follow up question. How do you handle a situation where one group might actually run sprints (during development), but others may just want to run a kanban board, basically no springs, just a prioritized backlog. Would you just advice that second team (Kanban team) to only use the backlog board and not the task board? Just curious to your thoughts on that.

        • You are exactly correct…although I find that teams that do Scrum or Kanban also find value in a kanban or scrum boards respectively (capitalisation deliberate)

  • Graham Bunce

    useful but not possible AFAIK with hosted TFS as you cannot change the template. Any suggestions for one big team working on many projects each with their own release schedules (devs can work on any project, sometimes on two projects at once) that works without changing the templates and works on hosted TFS?

    • I don;t understand what does not work with hosted TFS? All of the above works with both TF Server (Self-hosted & Hosted) as well as TF Service (Cloud) services… Nothing describes above requires you to change the template.

      You may be think of “Team Foundation Server 2012 Teams without Areas” which would require customisation, but you do not require to make that customisation to use many products and teams working in a single Team Project…

      Can you please specify what the issue is that you are encountering?

      • Hi,

        I may have misread your article but you say here:

        >In order to achieve this all I need to customise is to add a single new
        field to the Product Backlog Item. Is we add a “[mycustomer].Customer”
        field to the PBI and make it a drop-down-list of all of the existing

        This is not possible with TFS Service

        • Ahh.. I see the issue. The examples above were from a specific customer who did the “[mycustomer].Customer” field. That field is not required to create a single Team Project with many Products existing within it.

          “Nothing describes above ‘requires’ you to change the template. There may however be things that you would like to do that you would be restricted from in the Cloud.”

          I have many Team Projects on that have many products without having to customize anything… What are you finding that you need?

  • If you use a single TFS 2012 Project to manage business projects which exist in separate Areas how can you give each business project a separate home page (see screenshot)? You can add different backlog items from each Area (business project) onto home page, but it doesn’t look like you can create separate home pages. Scenario here is 2 teams of graduates working on 2 separate projects under same project manager – does this really require 2 TFS Projects or can you do it with one and give each team their own TFS 2012 Project home page?

    • You need to create a “Team” for each group. That will give them their own homepage and backlog.

      • Fantastic thanks! I’ve spent all afternoon trying to work that out…

  • Manish Jain

    As always, great article! I couldn’t agree more. Yeah, you don’t need new team project for a software project. It’s easy to manage with one team project (in our case, product company) and have great visibility. We have customized template (added functional area, product type etc) to filter/categorize items. I would create new team project when there is a group/team with completely different process. So let’s say company uses Waterfall process and newly acquired company uses Scrum.

  • Thanks for the great article. I work in a large company with our own TFS servers, and we have a wide spectrum of implementations. In some cases 1 TFS Project = 1 Product (and 1 team) and in other cases 1 TFS Project = 1 Division with 10+ products and 10+ teams, some of them are programs of teams, and others 1-2 person teams. We’ve been having this debate for quite a while.

    One thing you haven’t touched on is performance. We heavily use excel workbooks for project management, and the size of a project and collection have a HUGE impact. In some cases, the excel startup connection to TFS can take over a minute for a big project/collection, and in other cases it is as low as 10 seconds. We worked with Microsoft R&D for about a year on this issue. TFS2012 is slightly better as it will auto-delete old build entries in lists, but in TFS2010 we had to have custom SQL run every month to do this cleaning.

    We had been heading towards keeping our collections small, perhaps 1 per division, and our projects small. Another idea is to keep 1 collection per division, then just 1-2 projects in that collection, and make them mega-projects as you’ve described.

    Has anyone else tried both approaches and measured performance impacts?

    • If it is in the same collection then regardless wither it is in one or many projects you should have the same performance. In multiple collections your bottleneck may be the app tiers or your network capacity.

      As to scale. DivDev (Microsoft Developer Division) has a single team project that is over 17TB in the database so scale in a single team project is not an issue. Although I acknowledge the problem that you seam to be having and that you need to make sure you clean your databases effectively at scale.

      If you email me directly on “[firstname]@[surname].com” I will put you in touch with one of my colleagues that has just had to split a collection for performance reasons. He does however have 300+ divisions in TFS so it may not be for performance but for maintenance… lets figure that our.

      Each subsistent update for 2012 should improve the performance as the product team optimising for scale on Azure with

  • sriprasanna

    Great article. I really would like to use this strategy. But we face a problem now in Trials-

    We have multiple Teams and multiple work areas (distinguished based on product).

    We have one team as the ‘project default’ – this team comprises of all members involved and this team is assigned the root work area (including the sub-areas).

    We have individual teams assigned to their corresponding work areas.

    During the SPRINT planning the SCRUM master works on the root where the Team is the default team and all work areas are covered. He creates Backlog items, tasks and assigns it to specific area.

    He also fills in the capacity for all the members in the team for the current sprint.

    Problem is that this information on ‘Capacity’ of a member is not reflected in the ‘Team’ space to which the member belongs. So the Burndown chart (specific to team) doesn’t make sense unless we assign the capacity – specific to Team.

    I thought this strategy is useful for “One Master(One overview) – Multiple Teams” SCRUMs.
    Where from the root (project-of-projects) you can see the overall performance and from specific team you can see the team specific performance.

    May be I misunderstood the basic Idea.

    Could you please help me?

    • Capacity planning is done at the Team level and does not rollup. You could write a TFS event handler to rollup that data but I am not sure of the value.

      TFS 2013 solved this problem by removing Sprint planning from the parent Teams when not configured.So you don’t see those features and think that they work at that level…

  • Ben Whaley

    I found this article very helpful — thank you. You mention that Teams can be mapped to a Work Item Field Definition — can you please describe how to do this or point me in the right direction? Thanks!

    • I was just coming over to add that link 🙂 I am glad that you managed to find that post.

      • Ben Whaley

        Hi Martin,

        I have a few follow up questions if you don’t mind:

        1) I see that each team can customize the columns in its own Kanban/Backlog Board. Is the data behind these boards and the associated CFDs accessible for reporting? It doesn’t look like that data is stored within the Work Item itself.

        2) We’re interested in being able to produce CFDs both at the Team level and at the Team Project level. We’d like to be able to report on a number of metrics around this data, including cycle time between any two points on the board. At what point would it make sense to customize the Work Item Workflow States to match our Kanban board columns and to introduce custom date fields on the Work Item to track the transition dates?


        • 1) Currently the Kanban columns are not pushed through to reporting. If however you look at the history of the Work Item you will see a [Kanban Column]Team A = [Column] in there. The data is in the operational store and the Product Team have just not decided how to surface that data.

          I know that this is currently a pain and it is a major ask from most of my customers too. However if you do delve into the world of Columns per Backlog per team you will quickly encounter the issue… remember in 2013 you have multiple backlogs on the same team…

          2) If your base Kanban columns are consinstant across all of your teams then you will likely need to make that customisation to get the reporting. However you will have to accept the burden of updating all of the OOB RS & Excel reports to reflect that change. Indeed it will make your upgrades a little more complicated as well.

          First I would check out @tfsjeff’s TFS Kanban Tabular Model as a first rate solution that may require less work to implement.

  • Suraj Nair

    Very nice article Martin.

    I have a bit of different scenario, and I will at the outset say that this may not be so common.
    We have a fairly small team that works across various products. We manage our product classifications in areas and sub areas. We have various releases through out the year, one which is on a regular monthly cadence for product enhancement type work and a few other scattered throughout the year which are more like projects that could span several months. our team setup is volatile and is setup based on releases. So each release has a release team assigned to it depending on availability and requirements for the release.
    I know I can’t use iteration path as a way of setting up teams (like area paths), cause I tried and its not supported and of course iterations will keep adding on as time progresses and may not be the right thing to use. So the method to use a new field called team and updating common configuration seems to be the logical way to go. But my question is, is there a way I can possibly have this new field populate automatically with the leaf node of the iteration the work item is set to. I tried doing this and was not able to get it to work, cause of conflicting types. Any suggestions?

    Note: I have also had the pleasure of working with Martin in person on an onsite visit to our company.

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

  • Damian Reeves

    Nice article, but when you add a desire to use git as your version control system in TFS 2013 this all falls apart. A single teamproject for an organization means a single git repo for the organization. Managing things at the subfolder/subproject level get hard now. I know your answer, “don’t use git.” But git provides benefits and if we’d made the decision to go with git what is the guidance?

  • Thanks Martin for the article on one big project. It looks like my department is going to go that way. My question is this can I control my workflow based on Area. Meaning from the Proposed State If I changed my Area can I have Assigned to be changed based on that Area or Team. I have been testing with 2 groups set up in my Project level security and I am trying to get the Rules around ‘Assigned to’ to changed based on the Area that I change to. I have tried the two separate When Rules and 2 separate values ffor Area ID and have tried the same for WhenChanged Rule and did AllowedValues for the 2 different Security groups. Any ideas would be appreciated.

    • Larry, for no good reason there are limitations on what rules can be applied to the Area Path field. Gregg Boer has a good post on work around:

      • Thanks Martin. That article helped a little. I am using TFS 2012. My question centers more around contolling the Allowed Values for the Assigned To field. I am trying to dynamically have the ‘Assigned To’ field populate with a certain group based on what the AreaID is. Our Area are set at the same name as our team names and should stay at the top level. With each team there is a certain group of people that I want ‘Assigned to’ to populate with. Do you think this is possible?

        • That sounds like you should be able to use a WHEN clause on the AssignedTo field that sets the list based on Area Path.

  • Mike Gilmore

    I’ve worked for both GE Healthcare and Caradigm (formerly Microsoft’s HSG). We used this model at both companies to tremendous success. The Team Projects were divided among organizational boundaries (e.g. Dev had a Team Project, Ops another). I’m working hard to implement this at my current company, I believe this will be a great success story for the organization.

    • @disqus_2ig9eqTl3h:disqus , while I understand that you got value from this I do not recommend this way of working. Creating silos within your organisation (and separate Team Projects does do this) based on skill is a recipe for disaster. Instead of having functional teams from your organisations perspective many teams find it far more valuable and effective to have functional teams from the Deliverables perspective. Each team having all the required personnel to ship a code a code change from top-to-bottom in there application and Dev->Prod.

      Microsoft has been doing it ineffectively for many years and is only now (that’s one big ship to turn) moving towards a much more agile process. The only way to ship to production every three weeks as DevDiv does or at least every quarter as Xbox does (they actually have many smaller releases internally) and twice yearly as the Windows team now does is to break down those barriers and start creating cross functional teams…

  • Julie

    Holy smokes, thanks for this blog! I’ve been trying to implement TFS, and now that my proselytizing has gotten me somewhere, this is a great jump off point – It’s answered “the” question on how to set up TFS. Just a quick question – The CMMI template seems to have more of the workflow we are looking for as an organization – Especially the “Change Request” portion. How often do you find other orgs using this template?

    • @julie_steiner:disqus you should take a look at . Every company I have ever seen moves more towards the Scrum template, even if they take the Change Request ( although that in itself can be mitigated difernetly) and add it to the template. Did you know that the first ever Scrum project in 2001 was CMMI level 5 and for life critical systems. You can do CMMI and have the functionality of change requests without actually having a separate work item type.

      • Julie

        @Martin Thanks very much for the Link. I’ve started experimenting with the Scrum template. I think this one might be the winner. 🙂

  • Steve Davey

    Hi, my company are currently looking at moving to the single team project approach described in your article, I wondered if anyone that has previously made the switch had any feedback on performance impacts? are there any case studies around performance? thanks Steve

    • The TFS team at Microsoft currently have a single TP in a TPC that is over 27TB. Check out a post form 2009 ( on the performance and it has only gotten better since then. The same codebase runs on so it has to be performing…

      • Steve Davey

        Hi Martin, thanks for the reply.
        Have you encountered any issues with having multiple code bases combined in one TPC? we have many applications that we would ultimately look to intergrade into this approach, would this hamper build performance, or web view TFS response times?
        I can not access the blog that you posted a link to, I get a group does not exsist message on screen.

        • I fixed the link – and no, there are no performance issues that I have ever encountered.

  • Ann Taylor

    No one has touched on security. We have over 2000 developers and 500 applications. Some of the apps are grouped and deploy together but some are individual. There’s typically one set of developers that work on an app or group of apps. With one TP, we would have roughly 250 folders for each app or group of apps. How do we make it so that the teams that work on certain apps don’t have access to other folders in the tree? For instance, if we have a folder called “Product S” that contains subfolders that represent all the apps that make up “Product S” and then another folder called “Product R”, how do I assign folder permissions to restrict access? Access control is a huge deal in my company.

    • @disqus_JpKdbvPbHt:disqus its an interesting discussion. Now while you can do security at that level it does get a little messy. I would recommend that you look for those hard boundaries, where people are not working on, or switching between, different codebases. This is where you would have a hard boundary and to be hones I would do another Collection with a single Team Project. This will give you some ability to backup and restore more granularly and to scale more effectively. If PersonA works on Project S for a few years and then may move to Project R and will no longer work on Project S then this works great. If its a bug mess in there with everyone working on everything you really need to sort out that mess first.
      For almost all of my customers I have been recommending moving forward with Git Repositories in TFS. You create a single Team Project for work item tracking and have a distinct Git Repository per product. You can then permission the Repositories based on Teams.

  • Dianna

    You made this statement above “Now all we need to add is two teams in the new Agile Planning tools in addition to the default and configure them to only show their own backlog based on the Area Path (or we can configure it to use a Team drop-down”. Can you elaborate on how to implement the Team drop-down solution?
    I have one TFS project where they are using scrum 2.0 template. There are 3 Agile teams which work on all areas of the product. They have meaningless names like Red, Green, Blue because they are not dedicated to any particular area. Initially they set their area paths to Red, Green, Blue so they could assign work to those teams and have isolated Team backlogs. However Support and QA want to define real product Areas and we would like to report on those areas (e.g. report to show which area of the product has the most bugs). The problem is we have no way to then delegate work to each team if I can’t slice it along the Area Path. I could add a Team drop-down field but then how do I make it so that only items assigned to this team show in their backlog and use regular drag-drop prioritization? While I could create queries based on a team field, we don’t want to work in a query where we cannot prioritize. Thus I need a way for what shows up in the backlog to be contingent upon the Team field rather than area.

    • you have two options to resolve this:

      1) you can create a Product1 node and then add a Product1Green and a Product1Red as well as a Product2Green. Then the Green team ‘owns’ both of the Green nodes.

      this is the recommended way

      2) You can look at Team Field. With this you can create a new drop down for ‘team’ and use that instead of area as your tem designation.

      • Dianna

        Thank you so much for the link to “Team Field”!! I think this will solve our issue. The project actually contains just one large product with many functional areas so not sure the first solution can be used since an Area Path might look like “Framework/Admin/Red”. Red,Green, Blue would be duplicated everywhere for each functional area. I did think about doing the inverse however where I just duplicated the entire Area set of nodes under top-level nodes Red,Green,Blue but this also seemed sub-optimal.

  • Pingback: Creating nested teams in Visual Studio ALM | naked ALM - Experts in ALM, TFS & lean-agile with Scrum()

  • Pingback: Create a Release Management pipeline for Professional Developers | naked ALM - Experts in ALM, TFS & lean-agile with Scrum()

  • Pingback: TFS 2013 Work item, Limit Assigned To field based on the area you chose.()

  • Johnny Boldt

    Hi! Does a single team project still make sense with TFS2015, or has new functionality made it unnecessary? We are currently on TFS 2013 with multiple projects and it is clear that one project with multiple areas will solve a lot of our issues in terms of visibility and reporting. But we are also planning on upgrading to TFS2015, so I was curious if it still makes sense to consolidate to one project.

  • Corrine Bunnell

    Thoughtful discussion ! For my two cents , if your company are wanting to merge some PDF files , my husband encountered a service here


    Good article, Thanks!

  • Ashle Stewart

    Hi Martin is there a way of showing a Kanban board view of all work assigned to me across multiple team projects (same collection) – I am working with VSTS

    • No there is not. If you are in VSTS you might get some use out of the Planning hub, which does go across Team Projects, but everything else is bound to the Team Project.

      If you want to email me for options we can discuss further and in more detail.

  • Martin, could you clarify the following statement regarding Areas in TFS:

    “You can only have 254 areas per level”

    I’m using online Visual Studio Team Services (VSTS) rather than on-premise TFS. As a new administrator of VSTS, I have very limited experience so I want to confirm my understanding before proceeding with the implementation of VSTS for my company.

    To illustrate my concern, I’ll provide a brief example. Assume that a company is a consultancy that works on many development projects for many clients. Using the “One Team Project to Rule Them All” design, the consultancy might use the following structure for Area to separate access between clients while maintaining streamlined workflow and reporting for their projects:


    Based on my understanding of your statement, it would appear that this design will fail if the consultancy has more than 254 clients or if it has a client with more than 254 projects. If my understanding is accurate, could you suggest how to work around this limitation in the scenario described above?

    From my research, I know that large companies use the “One Team Project to Rule Them All” design successfully, so I’m wondering what I might be missing?


    • Correct. You should add a DropDown with the customer entries in the list rather than an Area Path.