Skip to content

Best Practices for Area and Iteration Paths in Azure DevOps

Key Terms

A Project in Azure DevOps (also sometimes referred to as a Team Project) has a backlog, at least one team, and may have one or many repos and pipelines. Additionally a project will have an artifact feed and a customizable dashboard. The current recommendation is to align projects in Azure DevOps with product lines or key capabilities (such as DevOps or Data Warehouse).

A Team is a group of people who work on a project or subset of a project. The current recommendation is to align scrum teams with teams in Azure DevOps. Note that a person can belong to many teams.

Area Paths

Area paths allow you to group work items by team, product, or feature area. The main use of area paths in a large project is to divide the project backlog into team backlogs. Area paths can be hierarchical and can also be used to further segment components within a project for querying and reporting purposes. See this Confluence page for more information around creating a team and more details about what a team in Azure DevOps includes.

For our use case a recommended best practice would be to follow a pattern like this: - Product-Line\Technical-Area\Optional-Technical-Subarea\Scrum-Team

This assumes that a product line is a project in Azure DevOps, and it is something that is typically released or at least managed in one unit. Some product lines are much larger than others so the suggestion above may not be the optimal solution in all scenarios. The key thing to note is that access to each area path can (but doesn't have to) be controlled with a team created in Azure DevOps, which should be controlled via a distribution list in most cases. In addition to specifying team's division of the project backlog, Area paths can also be used for additional groupings or querying of work items within a project. This can be done at any level of a project including under the scrum team as well.

Iteration Paths

Iteration paths allow work to be grouped into sprints, milestones or other time-related periods. It may make sense for tightly integrated teams to follow common iterations and/or to share major milestones or releases. However, it is not required that all teams (or projects) follow the same cadence.

Like areas, iterations can also be hierarchical. This means that a project could define release iterations or product increments and teams could define sprint iterations under the release iterations and each team could do so in a different way to reflect the way they work (e.g. one week vs two week sprints). A key consideration when defining iteration paths is that there must be dates defined on the iteration paths for many of the reporting mechanisms to work (e.g. in the Plans extension available for Azure DevOps).

Examples of a hierarchical iteration path: - Release 2.1\Sprint 12 - PI XYZ\21.11 - FY21\21.12

References:

  • https://docs.microsoft.com/en-us/azure/devops/organizations/settings/set-area-paths?view=azure-devops&tabs=browser
  • https://docs.microsoft.com/en-us/azure/devops/organizations/settings/about-areas-iterations?view=azure-devops