Understanding teams

When you develop software, you often work as part of a team, and often several teams work together as part of an organization. This release of Team Foundation Server (TFS) provides a set of tools and features that can help teams work together towards their common goals. With these features, you can:

• Manage the product backlog for your team.

• Use a virtual task board to help you run your team meetings.

• View your team's burndown and velocity.

• Divide up work across several teams, if you choose to have more than one team configured for your project.

Requirements

In order to follow the procedures in this tutorial, you must have the following:

• Visual Studio Premium, Visual Studio Ultimate, or Visual Studio Test Professional.

• To view team features such as the backlog and task board, you must belong to the Full access group in Team Web Access.

For more information, see Change permission levels, Change access levels, and Team Foundation Server Permissions.

Team Foundation Server and Teams

In TFS, a team is simply a way of recognizing the team or teams you already have, whether that is one team working on a project, or twenty. TFS turns the often-intangible details of who the team is, what the team is doing, and when the team expects to be doing it, into traceable, easily used information for each of those aspects. For example, the "who" of the team is represented in the membership of the team:

Abbreviated view of a team home page, including team membership list

For each iteration, you can also define the available capacity for each of your team members:

Team capacity pane, including example capacity information for each team member for an upcoming sprint

The "what" of the team, describing what work the team owns and is responsible for, is represented both by the area path or paths associated with the team, as well as the product backlog of tasks, bugs, and other work items that represent the work that needs to be done. If a work item is assigned to an area path that is assigned to a team, that work item is placed into the backlog for the team. The team then manages the product backlog, deciding if and when that work should be done:

Administration view of a team's areas. Any work item assigned to that area path will appear in the backlog for the team associated with that area path

The "when" of the team, describing when the work will be performed, is represented by the iteration paths the team chooses to work in. The team assigns work to a specific iteration, creating a backlog of work that the team commits to completing within that period of time:

Example backlog of work items and tasks for a sprint

Administration view of a team's iterations. Any work item assigned to an iteration that the team has selected to participate in will appear in the backlog for that iteration for the team

While working within an iteration, the team self-manages and tracks the work in progress by using the task board for the team:

Example view of a team task board

Although this might look complex, there is very little overhead in configuring and working with teams. When you create a team project, a team is automatically created for you and is linked to that project. This team is the default team, and it has the same name as your project, appended by the word "Team." For example, if you name a team project "Phone Saver," the default name for that team will be "Phone Saver Team."

The default team has an area path and an iteration path configured for it automatically. As soon as you choose areas and iterations for a team, a backlog is also generated for it automatically, although it might be empty if there are no work items assigned to the area path and iteration path configured for the team. When you add users to a team project, you can choose to add them to the default team, or you can choose to create multiple teams for a team project, and add users to the teams that they participate in. Alternatively, you can add users directly to teams. An individual user can belong to more than one team in TFS, just like a person can belong to more than one team in a software project. By default, the team group is added to the Contributors group for that team project, which grants all team members the permissions required to access work items and source code in that project, among other permissions.