Teams without areas using a team field in TFS

Did you know that you can use Teams without areas using a team field in TFS? There are numerous reasons to do this but the decision should not be taken lightly.

Although not the default it will give you greater versatility in configuring for a single Team Project with the ability to then use area solely for Product. Lets say that you have a bunch of products and four teams that work on those products. No team particularly owns those Products as you have many more Products than Teams and you have a single backlog of ordered work that represents work across all of those products.

Area Iteration Team
    |—Product 1     |—Release 1 Team 1
    |       |—Component 1     |       |—Sprint 1 Team 2
    |       |—Component 2     |       |—Sprint 2 Team 3
    |       |—Component 3     |       |—Sprint 3 Team 4
    |—Product 2     |—Release 2  
    |       |—Component 1     |       |—Sprint 4  
    |       |—Component 2     |       |—Sprint 5  
    |       |—Component 3     |       |—Sprint 6  
    |—Product 3     |       |—Sprint 7  
    |—Product 4     |       |—Sprint 8  
    |—Product 5     |—Release 3  
    |—Product 6     |       |—Sprint 9  
    |—Product 7     |       |—Sprint 10  

Indeed within a single Sprint a Team may touch multiple products and they are all released on the same cadence. Is this ideal… well no.. it can be hard to create working software against a single piece of software let alone multiple. But lets for a moment assume that all your products were built using TDD, they have a full automated UI suite of tests and every manual test is automated by the end of every sprint. Not only that but you have an automated and tested deployment that has been proven in Development, Quality Assurance and Production environments.

In short you have continuous delivery and you are good at it.

Now, while in this is a fantasy world for most companies there are yet others for which this is a reality. Look at the new 3 week shipping cadence of the Developer Division at Microsoft or the 6 week cycle for Chrome from Google.

You can’t ship code to production in the form described above unless you are that good. If you are not then good then you may think about working on one Product for a release and then moving that team to another product for the next release. That would be an easier way and allow your teams to focus on one thing for a release. Still problematic but a little more manageable.

There are only a few simple steps to achieve Teams without Areas with team field:

  1. DONE Create a Global List for ‘team field’ 
  2. DONE Add the ‘team field’ field to PBI & Bug
  3. DONE Change the CommonProcessConfig.xml file to use ‘team field’
  4. DONE Configure Team settings per ‘team field’

So lets get started.

Warning Never make changes against a production TFS… Ever… Always test out your changes in a test server first

Info If you are really awesome you should create CodedUI tests for all your common TFS user scenarios so that you can be sure that you have not broken anyone’s workflow without intent.

Create a Global List for the ‘team field’

We first want to create a Global List to hold our list of Teams. This is really for two reasons. First in the Visual Studio Scrum 2.1 process template both PBI and Bug are owned by team members and appear on the backlog so a Global List need only be updated once for both Fields. Second we can easily build a tool to add items to the list and even if doing it manually we are not in danger of radically changing our Work Item Type Definition ever time we want to add something.

Creating a Global List for the 'team field'
Figure: Creating a Global List for the ‘team field’

If your TFS server has not yet been in use for builds and you have never created a global list then you will be presented with an intuitive empty box.

Create a new global list for the 'team field'
Figure: Create a new global list for the ‘team field’

If you right click in the open space you will see a menu that you can use to first add a Global List and then populate it.

Add all of the Teams to the global list
Figure: Add all of the Teams to the global list

Once you have populated your global list we can then move on to adding the custom field to the work item type definitions so that we can both select it in the UI and set the administration configuration for it.

You can export your global list from the command line or through the UI for use on your production server once you have decided that this is the way for you.

Info Always store your changes in Version Control so that you never loose them. Preferable not in the server that you are modifying. is perfect for this.

Add the ‘team field’ to PBI & Bug

Now we need to add a custom field to all of the work item types that are defined in the  “Requirement Types” section of the Categories.xml file.  In the case of the Visual Studio Scrum process template this is both the Product Backlog Team and Bug.

Figure: Command line call to export categories

If you look in the file you will see an entry for “Requirement Category” that contains the things that we are looking for.

Figure: Requirement Category for Visual Studio Scrum 2.1

We need to update both or we will get an error, however we will be making the same change to both.

Edit the PBI to add the 'team field'
Figure: Edit the PBI to add the ‘team field’

This will open the Product Backlog Item Work Item Type Definition from our test project in a UI tool that will make it faster to get all of the way through the changes. The nice thing about the UI is that it has listed all of the options and I don’t have to Google or remember them… I am pretty lazy aren’t I…

Add the 'team field' to the PBI
Figure: Add the ‘team field’ to the PBI

I always follow the same format for creating custom fields. I think that most of the ALM MVP’s and Consultants out there do the same so…

The Name should be in the format “[what you want] ([comapny])”. This allows you to see which are custom fields in the cube. The reference name should be just the opposite with no spaces or special characters. So it becomes [company].[CamelCaseName] and allows me to also identify it easily.

I am setting this as a Dimension so that I can use it to slice any of my reports. You will need to modify the OOB reports to add this to them, but anything that you create you can add this out of the gate.

Adding the Rules to the 'team field'
Figure: Adding the Rules to the ‘team field’

I am adding two specific rules and you may add more but this is the basics. First add AllowExistingValues so that if you delete a team in the future you are not left with Work Items in a broken state. Then we need to get to the meat and add the AllowedValues.

Add the 'team field' global list to the allowed values
Figure: Add the ‘team field’ global list to the allowed values

The global list should appear in the UI and be selectable. This will load the values and create a drop down list on the UI (once we have added it) to allow users to select Team.

Figure: Xml for the ‘team field’

But we are not done yet. we still need to add the field to the UI.

Where to put the 'team field'
Figure: Where to put the ‘team field’

In the PBI form there is a nice little space below Reason that I want to utilise. So lets add the field to the UI.

Add a new control for the 'team field' data
Figure: Add a new control for the ‘team field’ data

We just need to add a new generic control to the UI where we want it. Most of the layout is taken care of automatically so we only have a few fields to fill out…

Set the field name and the label for the 'team field' to show
Figure: Set the field name and the label for the ‘team field’ to show

We have only added a simple reference to the data and Team Foundation Server will figure out how to render it on both Web and thick client alike.

Figure: The new control XML for the ‘team field’

Once you have added this you will need to refresh the cache in Visual Studio before you will see the new list on the Work Items.

New 'team field' is now on the form
Figure: New ‘team field’ is now on the form

Warning Remember that this field and control will need added to all of the Requirement Types that you have set for your process template.

Info The easy way to add this field to other work item types is to export the XML and add it manually.

Figure: Export both, edit the bug and then import it to add team without areas

Once you have added these changes to all of the Requirement Types that you have configured you can move on to configuring TFS to look at this new field and not Area.

Change the CommonProcessConfig.xml file to use the ‘team field’

We now need to tell Team Foundation Server to use this new field by changing the Common Processing Configuration that the web access uses to figure out what is going on with a particular process template.

Figure: Export the common process config to xml

Once you have the xml file you can open it in your favourite IDE and find the TypeField with the Type of Team.

Edit the TypeField for Team to use the new 'team field'
Figure: Edit the TypeField for Team to use the new ‘team field’

You can literally just change the refname from the current Area Path value..

Figure: Original Team value for TypeField

To the new Teams field that we created earlier..

Figure: New Team value for TypeField

Now save and import the new common process configuration we are nearly there.

Figure: Import new common process configuiration file

And we are almost done. we now need to go to the Web Interface and tell it for each team, what value is theirs…

Configure Team settings per Team without Areas

This is the final part of the configuration and once you go into your Team boards of backlog you will get a lovely message:

TF400512: You have not selected any areas for your team. You must select at least one area before you can use features such as the product backlog, the task board or tiles.

Well lets do what it says and head over to the administration pages for this team by clicking the nicely provided “Select team’s areas” link.

New Team Field tab has been added to the Administration
Figure: New Team Field tab has been added to the Administration

We now have a brand new tab on our administration section for “team field” so that we can select one or more “areas” from our new field values that this team is responsible for.

This is Team 1 from the list
Figure: This is Team 1 from the list

Now when we create new work items as part of this team they will default to selecting this drop down and not our Product hierarchy that is in Area Path.

Team is now set instead of Area Path by default
Figure: Team is now set instead of Area Path by default

If you were using this new drop down for Product rather than Team you may want to have multiple values owned by this team and that is allowed in the configuration. I would only recommend that however when you really need hierarchical teams that Area Path can provide or at least simulate.


This has merit when the situation dictates and I have recommended it twice now with some of my colleagues coming around to the idea.

And remember that any changes to your process template should be well thought out as you don’t want to end up with fragmented templates if you have more than one Team Project or worse, end up with a frankin-template that no one wants to use.

Just be careful out there…

  • Nice approach. I like it.

  • Gregg Boer

    Martin, as the Product Owner of the team that built this feature to use teams without areas, I could NOT have written a better post myself. Great work detailing out this approach. It will be very useful for teams that use area path for something other than team representation.

  • Pingback: Team Foundation Server 2012 Teams without Areas | Visual Studio ALM |

  • Pingback: Team Foundation Server 2012 Teams without Areas | Windows8 Programming |

  • This is cool Martin, thanks! Creating some interesting new possibilities for me now 🙂

    • I thought that you might find it useful based on our conversation 🙂 Happy to help…

  • Ron Overbeck

    This approach looks like a great fit for our company, but after following these instructions in TFS 2012, I discovered that the website sprint backlog view does not function properly. Adding a task using the website sprint backlog view appears to work at first. The task is properly linked to the PBI and you can see it on the board, however, once you refresh the browser the task disapears. Looking at the details of the task or PBI shows that they are still linked, but you can’t see the task on the board. Has anyone else encountered this problem?

    • Lockhouse

      Hi Ron,
      I’m having exactly the same problem. Did you find a solution?
      Best regards.

      • You need to have the ‘team field’ added to your Task work item type as well and it needs to be set the same as your PBI otherwise it will fall out of scope…

  • Pingback: TFS as perfect tool for Scrum (Part 2) – Product Backlog Grooming | The Road to ALM()

  • I like the idea of using another field (vs area path) to define the team. However I do not want to introduce a new field to my WITs. I use the iteration path field to control what my team’s backlog is. I setup a separate iteration path for my team and would like only those items to be displayed in the agile planning tools (backlog list) in TWA. Using TFS2012 RTM and agile 6.0 template. It drives me nuts that TWA does not allow to edit the baclog query. Any suggestions?

    • I have not tried to use System.IterationPath and I don’t know what impact it would have. You are a little off the beaten path as I have only ever seen Area or a drop-down-list used for Team 🙂

      How would you support two teams on the same cadence? Do you have two separate “[teamA]Sprint 1” and “[teamB]Sprint 1”?

  • Андрей Зонов

    This is noce approach, we also using in our project, but with latest Update 2 we faced an issue – new feature of accessing test cases from the web interface doesn’t work because of it assumes we are using Area as a team field. I’ve created an report on that for Microsoft (, but don’t know how big are the chanses that this will be fixed soon.

  • Pingback: Teams without Areas–Fixing the reports | The Road to ALM()

  • Pingback: Working within a single Team Project with Team Foundation Server 2012()

  • Peter

    Do you know,if it is possible to add more than one Global List for team fields? Maybe there is the need to have different team names in different projects with different Project administrators in our company. So ervery administrator is responsible for his own list.

    • Yes you can. You can create a Global List for “TeamProjectA-Teams” and then customize every Team Project independently. I would however recommend one Team Project per Collection…

  • Pingback: Configure Test Plans for web access in TFS 2012.2()

  • Ben Whaley

    I’m interested in making this change in the TFS 2013 Preview, but my understanding is that Power Tools for that version of TFS are not yet available. How difficult is it to make these changes without those tools? Thanks!

  • Scott Wollschleger

    I just stumbled upon this and tried this out in a test environment. The issue I see is the Team field is not auto populated in linked PBIs or tasks (add a child PBI or Task). Is there anyway for this to carry over like AreaPath, IterationPath, & Assignedto fields do?

    • If you break down the PBI into Tasks or Child PBI’s using the ‘green’ plus in teh Agile Planning and Portfolio tools it does. If you do it on the Work Item it does not… I have reported this to the Product Team…

  • Jeff Smith

    Hi Martin. We have this configuration implemented just as you instructed. One thing we’re noticing is that when you are logged into a specific team within your project in web access and you are in a sprint backlog view and use the + icon to create a new task, the team field defaults correctly on the task. However, if I open a bug or pbi and choose to go to the Task tab and use the New Linked Work Item… button to create a new task, that new task’s team field defaults to Unassigned. How does it know to default to the correct team when I use the + icon or when I right click on a bug or pbi and create a new task?

  • Pingback: TFS 2013 Issue - value cannot be null. Parameter name: key()

  • Renaldas Budrys

    I implemented this in test TFS environment and encountered a few issues.
    Environment: VS2013 using Agile template
    – Global list created with two teams: Red Team, Blue Team
    – All required work items updated Agile template (Bug, US, Feature,Task)
    – Rules: allow existing values, allowed values coming from the global list
    – Common process template changed to use Team instead of Area Path
    Issue 1:
    TWA forces to select at least 1 Team for the backlog even for the default project team. I selected Blue and Red teams (all teams) on the team field tab. However, when I do that all the work items that have no value in the Team field fall out of scope even for the default team. I can catch extract them all in excel and set the team and publish back to TFS to fix that. Is there a more elegant way to deal with that.
    Issue 2:
    When adding new work items to the backlog we may not know at that time to which team those items going to be assigned. What to put in the field name before that triaging is done?
    Issue 3:
    MTM does not force to select a team for new bugs. If the bug is created from MTM has a blank team value it falls through the cracks. It will not appear on any team backlog. Without someone periodically auditing all work items it would be impossible to catch all these “missing” items.
    I am sure that there are multiple ways we can solve these issues. E.g. setting up the default team in the global list, making it as a default value, or simply enforcing field rules. Please prescribe the cure.

  • Anthony

    Hi Martin

    Should the team field be added to the code review and request work items?

    • Yes it should. You will also need to add a “default” so that you don’t get any errors.

      • Anthony

        Thanks. Can the default be changed when the code review is being created?

        Otherwise is there a way to get the team field to appear in window when the code review is being created?

        • No, and no. However the team field value is immaterial at the code review level. I usually add a default of “TeamProjectName”. Code reviews always end up here.

          • Anthony

            thanks for the quick replies.
            Re: TeamProjectName………I would assume I would need to create a dummy/default team name that has the same name as the project name?
            at the moment I have no ‘unassigned’ team field option and all options are assigned to the required TFS teams

          • I would add an “unassigned” team to the list… that way its obvious what it is and you can assign it to every or none of the teams…

          • Anthony

            Hi Martin, how do I get around the scenario around Test Plans and Suites not using this field? currently I have an error when I try to save a test case using the grid view since the field is not in these workitems

            from my understanding, I cannot export Test Plans and Suites unless I install TFS to update 3
            do you have a workaround or another way to update the Suite and Plans?

          • update 3 is the solution, but you can work around it by adding a value to team field with the same name as the team project.

          • Anthony

            Hi again. Not sure what you mean

            Do you suggest if the project name is ‘Anthony’ then the default for test cases is ‘Anthony’?

            I looked at some other posts and I am a little stuck


          • add an entry to your company.teams global list of the same name as the team project. Then make sure that each test plan has only the route area path set.

          • Anthony

            Hi Martin,
            me again. i found that when i went to add the field to test plans and suites after moving to update 4, i lost my current sets of test plans

            how do i get what i had in place with my test cases without having to re-add everything?

          • ANthony

            Hi martin,

            I had an issue with the team field yesterday
            I updated the globalist to include a new selection/team option and when the update was completed, the reference for the team field inside the workitem xml was removed
            somehow updating the list made all the workitems remove the referencing field
            have you ever experienced this?

          • That’s not even possible, there is something else going on. There is not relationship between GlobalLists and Work Item fields.

          • Anthony

            Wish there was another reason. Any help would be appreciated.

            To find the issue i had to find a tfs restore point and pointed that to a test environment. Then I compared the work item xml’s between environments. The globallist reference under the team field was deleted under all work items. all I had was a blank field and workitems that wouldn’t save.

            The work items files were never touched only the globalist.xml. I only touch the workitems when a new field is added and that had been weeks since they were touched. I added a new option in the globallist, imported and the damage started

            Had to reimport all work items xml’s again to fix the problem.

            Happy to discuss more

          • Are you sure that there is not an automated process that updates the work item template? Can you replicate the issue?

          • ANthony

            100% no automation and I didn’t import an old template.
            reason being I usually keep the xml files locally as a reference. but I was in a transition mode with a new laptop and so I had no files on my new laptop at that time
            I exported the globalist using the developer command prompt, updated the list and re-imported

  • jwhousley

    We are having an issue. We implemented the Team Field changes but we are having permission issues creating test plans and test cases from the TEST tab/screen. It appears that the Project Admin role is the only role that will allow things to work correctly.


    • If you are on 2013.3+ you must add team field to the Test Case, Test Suit, and Test Plan types as well..

  • Sam

    Very nice post. Just found this while searching for “nested teams”.

    I want to achieve something which seems like obvious if TFS team could offer nested teams feature. I need to setup TFS project with structure as:

    -> Location01_TeamProject (TFS Project):
    |–> TeamLead01_Team (Team at TFS project level)
    | |—>Product01_Team (Nested Team)
    | |—>Product02_Team (Nested Team)
    |–> TeamLead02_Team (Team at TFS project level)
    | |—>Product03_Team (Nested Team)
    | |—>Product04_Team (Nested Team)
    Any thoughts are appreciated.

    • Yes, TFS supports nested teams and they can be setup in both Area Path and Team Field modes. With Area Path your hierarchy is already available and each sub team just owns the area path below below. You can then choose to configure the parent team to see sub teams items or not. I regularly do this to support:

      – PMO
      |—Product 1 PO
      |—Team A
      |—Team B
      |—Product 2 PO
      |—Team C
      |—Team D

      It works pretty much the same with Team Field except you have to add explicit ownership of Team A and Team B as well as Product 1 to the PO Team for Product 1.

      If you need any help then give me a shout through the contact page 🙂

    • That’s pretty much what I have above, just with different names. You use Area path to create the nest and then assign area paths to teams…

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

  • Sandy Lada

    The only problem with this is that now I can setup a URL for a team but not a project. I need to be able to decouple teams from projects so that my project team can see everything on the project and the scrum team can see all the work assigned to them across multiple projects. The only URL I can setup now is for the Team.

    • Correct, in your situation that is the correct solution.

      However the optimal solution is to stop focusing on Project and instead focus on Product. Having a Project delivered does not necessarily contribute to value for the customer. In fact the opposite is mostly true based on analysis by the Standish Group in Boston. In Scrum a Sprint is the only Project, and thus the only thing that can fail.

      In order to get half way there you can use queries as above. Projects don’t get backlogs, that’s for Products.

  • Ben Whaley

    Do you know if this will work with TFS 2015 (on-prem)? Thanks!

    • Ben, Team Field only works on-perm. You can’t customise to this level on VSTS.

  • Barbara Göller

    Hi Martin. Is it possible to also define a team and its corresponding default team value within the process template? When using the AreaPath for the team assignment this can be done in the file GroupsAndPermissions.xml (cf. screenshot) but I did not find a possibility to do this when using a team field. Thanks for your help!

    • Not within the process template. The Teams are listed in a Global List and when you create a Team in the Web tool you need to specific which values in the Global List relate to that team.

  • Leo Dsouza

    Will the Team field show up on the TFS 2015 REST api?

  • Scott LeWarne

    Hi Martin, this approach is something that my team could greatly benefit from due to how we have a few teams working on multiple products, but our company has moved away from TFS to VSTS. Do you know if there are any plans to eventually support this approach in VSTS, or is it something that will likely never happen due to different architecture? Thanks

    • Its been discussed a few times, and I am pretty sure its on the backlog. I do however have many teams that use this approach wihout team field. You can do it with Area Path as well…

      • Scott LeWarne

        Well our problem right now is that teams are tied to area paths and we would like to separate them so that a work item can be in a particular area path (product backlog) but show up under a team. Can that be done with just area path’s?

        • NO, you would have to use Area Path for Team. You can… but it would mean either doubling up on Area or Team in the tree and would be very painful…

          Feel free to email me for a longer discussion.