Teams and TFS Groups in TFS11, the backlog, board and security settings.

Back to the ‘teams’ topic, it is new in TFS11 … (see below the previous posts about this topic)


Beside using the new team concept in TFS11, you also just can do it the ‘old’ way. Put all your team members in the different TFS Groups (readers, contributors, … ) and give them access to the team project. Just as you did the past decade. But, you have to understand what happens when you do it. You also can mix things, create teams and only add TFS groups to it, or give people specific rights within a team… actually you can make it a complete chaos. In this post some usages scenarios. (at the end of this post a final conclusion, maybe you want to read that one first.)


Scenario 1: A team project with no teams and only team members in TFSgroups configuration.

When you create a team project, you get by default a team with the team project name, prefixed with ‘team’. This default team has one member, the creator of the team project. Which as you can see I deleted.


When you browse to the administration page, you will notice that you can’t delete the default project. but, with no members it can’t do any harm.


Next, you can start adding members to the different TFS groups. For example I added several people to the contributors group.


Following step, make security settings for the different groups... for example for the iterations


or the areas. You can find it at the same places as you can in VS2010.


Interesting is that the security settings for the source repository only can be set in Visual Studio.



When you have a team project without a team (beside the default team), you do have a backlog, with a board.


Everything works as expected, only the capacity planning seems to be broke. The ‘only members in tfs groups’ project gets a bit more complicated when you start working with area’s. For example add two sub-areas and mark one of them as current.

Good to know when you mark the parent area as the current one you can set a child area as default. When adding backlog items by using the backlog it will automatically set the area property. 


Doing this and adding PBI’s and backlogs to the this area. Will result in a new backlog and new task board, helping the team members (which are only in TFS groups) to focus on this specific area only. Set the area setting to the parent area, including all sub area.. will result in a combined backlog.

The only thing what stays the same when changing the areas for your team project are the Team favorites (we don’t have a team :) and the queries behind it don’t have a current area path clause. You could add it yourself.



It is possible to create projects without using the new Team concept. Things look a bit strange, we have team favorites but no team members for example. But the main functionality works. It only gets a bit complicated when you start using areas and make different people responsible for different areas. You have to swap between the admin page and the home screen when you want to see a different backlog / functional area.

Scenario 2: teams only


I created two additional teams for the two different areas, added the team members to the default team and added the default team to Team 1 and 2.

All teams are in the contributors TFS group, resulting in the fact that all team members have the same security settings.


Having you teams setup in this way, gives them the easy capability to swap between the teams. The backlogs are up to date and the team capacity planning works. One annoying thing, the team favorites, the work item queries, are the same for the whole project so I have to create queries for every team and add them as team favorite.



Scenario 3: teams with tfs groups

Another scenario, for playing with security, teams and TFS groups is… adding the team members to TFS groups and add these groups to the teams as members. Now, you have members in your team with different security settings. Doesn’t feel really scrum, but it works.


Only the TFS Groups Readers and Contributors in the the default team and Team 1 and 2 have only the default team as team member.


Scenario 4 and 5 Teams with team members with specific security settings. 

The last scenario, is where you add only users to your team and set explicit security settings per team members.


I won’t recommend this, you really can’t administer this.

Final Conclusion.

So, after this small journey across the different possibilities of configuring security settings in TFS11, I must say… Be careful, you can create chaos which you aren’t able to administer anymore, and think up front about your areas and team structure, it influence the usage and capabilities of the nice agile tools.

  • Scenario 1: No Teams only TFS groups with Team members.
    You can use the backlog and task board,  the capacity planning doesn’t work (yet?). It gets complicated with multiple areas and multiple backlogs. For example when you want to use a bug backlog, don’t use this scenario go for number two or three.
  • Scenario 2: No TFS groups only Teams with Team members
    This feels like the only real agile solution, all team members have the same security settings and the usages of multiple backlogs is easy.
  • Scenario 3: Teams with TFS Groups with specific security settings
    When you want to have team members with different security settings, this is the way to go. Areas and multiple backlogs are fully functional including the capacity planning.
  • Scenario 4: Teams with Team members with specific security settings
    Forget this one… you will go crazy over time
  • Scenario 5: Teams with Team members with specific security settings and with TFS Groups with specific security settings.
    You not only will be crazy you probably will have to go to the hospital when you try to maintain this scenario.

For now… number three is my favorite, number two is more pure… one is ok, four and five not ok.

Comments (5) -

Eric Demeter 1/20/2012 12:03:07 PM

     Scenario 5 is the ONLY way a real development shop can use TFS, I have a few questions: how do you suggest to manage developers NOT overriding Gated Check-ins, restricting who can manage test plans, who can delete Lab Management VMs, who can enter bugs via Web Access Workitem only view?! is our TFS Team Security Model( It's complex....but you know what it actually WORKS and is really, really beneficial. Different Stakeholders can have just the right level of access....and it complies with our SOX audits.

So instead of making flippant comments and showing juvenile/amateur team models how about digging deeper into how DEV11 makes sense for real customers.

DEV11 looks interesting...and we'll agree that TFS Security is a nightmare...but we're  hoping that Dev11 will make TFS Security better (uservoice seems to agree -

Eric Demeter 1/20/2012 12:05:12 PM

The link to our security model didn't post correctly.

Here is the link:

@Eric... that security model looks interesting, is it just for one big team project. Do you realy need al levels? and do you use different security levels for the testers ... also interesting and hard to understand...

curiouse how you are going to handle it in dev11 with the backlog and task board.

Eric Demeter 1/20/2012 4:02:24 PM

We've long ago realized that having multiple team projects is a nightmare. Multiple team project just don't work (period). You can't move : history,work item numbers, lab management templates, build symbols, test results, test impact data, etc, etc, etc.

Therefore, after many painful years we've consolidated over 1100 users into using 1 Team Project. Area path\Iteration Path\Lab Management(TFSLabConfig)\Version Control\Work item Required Fields\ Work item custom states\Work item custom rules\Custom Excel Workbooks\Custom SharePoint sub sites\ Custom SQL Server Reporting Servers reports are are in place and I should mention it works really well.

It's been HELL getting here....But it of the key pain points we have seen is the fact that we have to standardize on English as the TFS artifacts are language aware (like sharepoint).

We're looking at Dev11 and at the moment the Dev Preview \ TFSService Preview is crap. C-R-A-P. But it's a preview
so we're not expecting much.

However, in terms of the backlog and taskboards...we're hoping there is a way to have backlogs and taskboards per team within our team project, and have backlog and taskboard permissions cascade from the Team level down to our 2 roles (Standard Role and Lead Role).

In looking at Dev11 so far we've been seriously underwhelmed and it feels the Microsoft is building a product that is 5-7 years behind the Accept/Rally/Version1 products currently in market.

From what we've heard from source at MS the upgrade path from 2010 to Dev11 is non-existent which means we'll have to write tools over the course of 18 months to figure out how to get our custom stuff to be able to be on 2012. It's a shame that Microsoft is so focused on the shiny new stuff of Azure that there not focusing on the bread-and-butter customers they already have (who are invested on their current platform).

It's an uneasy feeling and if it's going to take us 18 months to month to upgrade to using DEV11, I'm not sure our executives will look kindly to considering DEV12....and therefore the GITs and TRELLOs of the world start to look mighty impressive and cost affective.

Seeing how your an MVP what's your should we approach custom security groups and custom permissions to be able to BEST take advantage of the new whizbang backlog and task board features in Dev11?

I don?t even know how I ended up here, but I thought this post was great. I do not know who you are but certainly you're going to a famous blogger if you aren't already ;) Cheers! <a href="";></a>

Add comment

Şarkı Sozleri