To implement the Scaled Agile Framework (SAFe) in Azure DevOps, you need to translate its hierarchical structure onto the platform. SAFe organizes work across three main levels: Portfolio, Program, and Team. In Azure Boards, we use two key settings to mirror this structure: Area Paths and Iteration Paths.

Area Paths represent ownership and organization. Think of them as the "who" and "what"—which team owns this feature, or which product area does this work belong to? Iteration Paths represent time. They define the "when"—which Program Increment or Sprint is this work scheduled for?

Properly configuring these two hierarchies is the foundation for managing work flow, ensuring visibility, and aligning multiple teams toward common goals.

Area Paths allow you to create a hierarchy that represents your organization's structure. For SAFe, this means setting up a structure that mirrors your Agile Release Trains (ARTs) and the individual teams within them. The top level is your project, and each subsequent level drills down into a more specific area of ownership.

For example, a project named "MyProject" might have an Area Path structure that looks like this:

With this structure, you can assign work items (like Features or User Stories) to the appropriate team or ART. This allows you to create team-specific backlogs and boards while also enabling a higher-level view for Program and Portfolio management. For example, the "MobileApp-ART" team can see all work across Alpha, Bravo, and Charlie, while Team Alpha only sees its own backlog.

Iteration Paths, also known as Sprints, define the timeboxes for your project. In SAFe, the primary timebox at the Program level is the Program Increment (PI), which typically spans 8-12 weeks. Each PI is composed of several smaller iterations, usually two weeks long, called Sprints.

To align everyone on an ART, all teams must operate on the same schedule. This means they start and end their PIs and Sprints at the same time. We configure this synchronized cadence in Azure Boards by creating a parent Iteration Path for each PI, with child paths for each Sprint within that PI.

Here's how you might structure Iteration Paths for a year:

The "IP Sprint" is the Innovation and Planning sprint, a common practice in SAFe that provides a buffer for PI planning, innovation, and infrastructure work.

Once the project's Iteration Paths are defined, you configure each team to use them. The program-level team (e.g., "MobileApp-ART") would subscribe to the parent PI iterations, while the individual Agile teams (e.g., "Team-Alpha") would subscribe to the child Sprints within that PI. This setup ensures every team's sprint board is automatically populated with the correct dates, keeping the entire ART in sync.