Team area

The structure of the project teams is defined by a hierarchy of team areas. Use team areas to manage team membership, roles assignments, and team artifacts.

Team areas serve the following purposes:
  • Define the users (team members) on the team and specify their roles.
  • Define the timeline in which the team is participating. For example, a project with both new product development and current product maintenance might define a timeline and team area for each.
  • Customize the project process for the team.

Team areas are optional. A simple project with a small number of users might not need separate team areas. Instead, all work is done in the context of the project area.

Complex projects can have a hierarchy of team areas. Typically, one or more teams are assigned to each timeline. Users might have multiple assignments that require them to work on more than one team. Some project members, such as the project lead, might not belong to a team area, but are defined as members at the project level.

Team areas inherit the process and timeline of their parent, which can be the project area or a parent team area. They can customize the aspects of the process and when allowed, override all or portions of it.
Note: If, after you create a release plan for a team area, you move that team area to a different timeline and create a new release plan, any work items that were assigned to iterations in the original timeline remain in the original release plan. Those work items are not visible in the release plan that is associated with iterations in the new timeline.

Project work items belong to only one team area. Over time, a work item might be triaged to another team area within the project area.