Introduction to Microsoft Team Foundation Server

TFS controls access through three inter-connected functional areas:

• Access level management controls access only to features provided through TWA, the TFS web application. Based on their user license, administrators grant access to Basic, Advanced, or Stakeholder (previously labeled Standard, Full, and Limited) set of features.

• Membership management supports adding individual Windows user accounts and groups to default TFS groups. Also, you can create TFS groups. Each default TFS group is associated with a set of default permissions. All users added to any TFS group are added to the Valid Users group. A valid user is someone who can connect to the team project.

• Permission management controls access to specific functional tasks at different levels of the system. Object-level permissions set permissions on a file, folder, build definition, or a shared query. Permission settings correspond to Allow, Deny, Inherited allow, Inherited deny, and Not set.

Each functional area uses groups to simplify management across the deployment. You add users and groups through the TFS web service administration pages. Permissions are automatically set based on the TFS group that you add users to, or based on the object, project, collection, or server level to which you add groups. On the other hand, access level management controls access for all users and groups at the server level.

Here's what you need to know about permission settings:

• Allow or Deny explicitly grants or restricts users from performing specific tasks, and are usually inherited from group membership.

• Not set implicitly denies users the ability to perform tasks that require that permission, but allows membership in a group that does have that permission set to take precedence, also known as Inherited allow and Inherited deny.

• For most groups and almost all permissions, Deny trumps Allow. If a user belongs to two groups, and one of them has a specific permission set to Deny, that user will not be able to perform tasks that require that permission even if they belong to a group that has that permission set to Allow.

  For members of the Project Collection Administrators or Team Foundation Administrators groups, Deny doesn't trump Allow. Permissions assigned to these groups take precedent over any Deny set within any other group to which that member might belong.

• Changing a permission for a group changes that permission for all users who are granted that permission through their membership in that group. In other words, depending on the size of the group, you might affect the ability of hundreds of users to do their jobs by changing just one permission. So make sure you understand the impact before you make a change.

What permissions do I need before I can add users and manage permissions in TFS?

To add users or groups to your team project and manage permissions for your team project, you must belong to the Project Administrators group for that team project, or have Edit project-level permissions set to Allow. Project Administrators are granted the following default permissions.

To manage users, groups, or permissions for all team projects within a collection, you must belong to the Project Collection Administrators group, or have Edit collection-level permissions set to Allow.

TFS Area and Iteration

In TFS, areas are used to group work items based on product, feature, or business areas.  You can define area paths at the project level and assign them to a team under the team configuration. You can also create a hierarchy of area paths to support subcategories within categories.

New projects contain a single, root area that corresponds to the project name. A team is created with the same project name and the root area path is assigned to that team.

Add areas when you have these requirements:

• Filter queries based on a product or feature area
• Organize or group work items by team or sub-teams
• Restrict access to work items based on their area.

In TFS, iterations are used to group work into sprints, milestones, or other event-specific or time-related period. You define as many child iterations as you need to reflect your project lifecycle. These paths represent a series of events, such as sprints, pre-beta and beta deliverables, and other release milestones. Teams typically leave work items assigned to the team's default iteration if they are not yet scheduled for work or for a release.

Add iterations to support these requirements:

• Define sprints your Scrum teams use to plan and execute their sprints
• Set up more complex multi-release and sprint cycles
• Filter queries based on sprints, milestones, or cycle time for your project
• Support future work that you're not ready to assign to a target release cycle.

Most teams choose one area path and several iteration paths to support their work tracking activities. However, to support other scenarios, it's possible for teams to choose several area paths to appear on their backlogs and boards.