About teams and Agile tools

Azure Boards | Azure DevOps Server 2019 | TFS 2018 | TFS 2017 | TFS 2015 | TFS 2013

Adding a team is the #1 way in which Agile tools support a growing organization. Once your team grows beyond its optimum size—typically anywhere from 6 to 9 members—you might consider moving from a one team structure to a two team structure. For enterprises adopting Agile tools, setting up a hierarchical team structure provides several advantages to portfolio and program managers to track progress across several teams.

This article describes how to structure teams and how they are used. For the step-by-step procedure to add a team, go to Add another team.


For guidance on configuring and customizing your project and teams to support your business needs, review Configuration and customization of Azure Boards.

Depending on the size of your organization and your tracking needs, you can set up a team structure similar to the one shown. You do so by defining teams and their associated area path(s).

Each team has its own view of the work

For example, each feature team can be associated with a single feature area path—such as Customer Profile, Shopping Cart, Email—or several area paths. Each management team, which focuses on a set of features, can choose several area paths to monitor. This allows each feature team to have their distinct backlog to plan, prioritize, and track their work. And, portfolio or product owners can create their vision, road map, and goals for each release, monitor progress across their portfolio of projects, and manage risks and dependencies. To learn more, see Portfolio management.

Each team gets their own set of tools

Each team you create gets access to a suite of Agile tools and team assets. These tools provide teams the ability to work autonomously and collaborate with other teams across the enterprise. Each team can configure and customize each tool to support how they work.

Agile tools, team assets


In addition to team dashboards, you can add a project dashboard which isn't specific to any one team. To learn how, see Add, rename, and delete dashboards.

Agile tools, team assets

Agile tools, team assets

These tools reference the team's default area path, iteration path, and selected sprints to filter automatically the set of work items they display. To learn more about each tool and the configuration settings for each tool, see the corresponding articles.

Area Tool Team configuration tasks
Sprints and Scrum
Kanban boards
Other tools Not applicable
Area Tool Team configuration tasks
Sprints and Scrum
Kanban boards
Other tools Not applicable

Many of these tools are built from system queries that reference the team area path. For example, a team's default area path filters the work items that appear on a team's backlog. Also, work items that you create using an Agile tool auto-assign the areas and iterations based on team defaults.

Team defaults referenced by backlogs and boards

What work items appear on team backlogs and boards? When you add work items to a backlog or board, how are team defaults used to assign field values?

Teams are associated with one or more area paths and a backlog iteration path, which determines what items appear on their backlogs and boards.

When you define a team, you define the team's:

  • Selected area path(s)
  • Default area path
  • Selected iteration path(s)
  • Backlog iteration path
  • Default iteration path

All Agile tools reference the area path(s) defined for a team. The set of work items that appear on a backlog or board depend on the current State of a work item or its parent-child status.

Several tools reference the team's default iteration and selected iteration paths or sprints, also. Such as, when you add new work items from a backlog or board view, or from a team dashboard, the system assigns the team's default area path and default iteration path to these work items.

Agile tool Area path
(see note 1)
Iteration path State
Portfolio or product backlogs Selected area path(s) Equal to or under team's backlog iteration path Active (corresponds to a Proposed or InProgress state category, see notes 2, 3)
Kanban boards (see note 4) Selected area path(s) Equal to or under team's backlog iteration path Any state (see notes 3, 5)
Sprint backlogs (see note 4) Selected area path(s) Team's selected iteration paths Any state (see notes 3, 5)
Task boards (see note 4) Selected area path(s) Team's selected iteration paths Any state (see notes 3, 5)
New work item widget Default area path Default iteration path n/a


  1. Agile tools filter items based on the team's selected area path(s). Teams can choose whether to include or exclude items assigned to subarea paths.
  2. Work items whose State equals Closed, Done, or Removed (corresponding to a Completed category state) don't appear on portfolio and product backlogs.
  3. You can add custom workflow states and assign them to one of three state categories. The state categories determine which work items appear on backlog and board views.
  4. Kanban boards, sprint backlogs, and task boards only show the last node in a hierarchy, called the leaf node. For example, if you link items within a hierarchy that is four levels deep, only the items at the fourth level appear on the Kanban board, sprint backlog, and task board. To learn more, see parent-child links between items.
  5. Work items whose State equals Removed don't appear on boards.

Structure hierarchical teams or scale agility within an enterprise

Although there's no concept of subteams, you can create teams whose area paths are under another team, which effectively creates a hierarchy of teams. To learn more, see Add another team.

Also, the following articles walk you through the steps for configuring teams, area paths, and iterations to support portfolio management or enterprise organizations:

Team groups

When you add a team, a security group is automatically created with the team name. You can use this group to filter queries. The name of team groups follows the pattern [Project Name]\Team Name. For example, the following query finds work assigned to members of the [Fabrikam Fiber]\Email team group.

Web portal, Queries page, Query that uses In Group operator and team group name

You can also use the @mention control within discussions and pull requests to notify all members of a team. Start entering the name of a team or a security group, select the search icon, and then select from the options listed. To learn more, see Use @mentions to further discussion.

Work on more than one team

Can a user account belong to more than one team?

Yes. When you add user accounts to a project, you can add them as members of the project, or you can add them to one or more teams added to the project. If you work on two or more Scrum teams, you'll want to make sure you, specify your sprint capacity for each team you work on.

Team member permissions

By default, team members inherit the permissions afforded to members of the project Contributors group. Members of this group can add and modify source code, create and delete test runs, and create and modify work items. They can collaborate with other team members and collaborate on a Git project or check in work to the team's code base.

Default permissions assigned to team contributors

You can choose to limit access to select features by making a user a Stakeholder or limiting their access to read-only. For an overview of default permissions and access assignments set for work tracking features and built-in groups, see Permissions and access for work tracking.