Rediger

Del via


How SAFe® concepts map to Azure Boards artifacts

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

If you're interested in using Scaled Agile Framework (SAFe®), you can configure your Azure Boards project to track SAFe® deliverables. Just as Azure Boards supports Scrum and Agile practices, it can support SAFe® and large numbers of teams to work together on Epics that span releases.

This tutorial illustrates how the following SAFe® artifacts map to specific Azure Boards artifacts.

  • SAFe® Agile, program, and portfolio teams
  • SAFe® deliverables such as epics, features, and stories
  • SAFe® Product, program, and portfolio views
  • SAFe® Release trains, sprints, and other timeboxes
  • SAFe® Iteration goals and objectives
  • SAFe® Value streams and budgets
  • SAFe® Portfolio Vision and Strategic Themes
  • SAFe® Roadmaps
  • SAFe® Milestones and events
  • SAFe® Retrospectives and reviews

For an overview of how Azure Boards implements Scrum and Kanban, see About Sprints, Scrum, and project management and About Boards and Kanban.

Note

This article is one of a set of Scaled Agile Framework® tutorials that applies to Azure Boards and Azure DevOps Services. Most of the guidance is valid for both the cloud and on-premises versions. However, some of the features and procedures are specific to the cloud or the latest version of Azure DevOps Server.

The following image illustrates how you can configure Azure Boards to support a three-level team hierarchy and map teams to their respective area and iteration paths. The examples build from the Agile process, However, the changes can be applied to any project and process hosted on Azure Boards.

Agile tool structure to support SAFe®

Examples provided below illustrate how a three-level team hierarchy is configured using hierarchical area paths. The examples build from the Agile process, However, you can apply these changes to any project hosted on Azure Boards.

Agile feature, program, and portfolio teams

Azure Boards supports each team to have its own view their work. By configuring a hierarchical team structure, each team can focus on their work, and have their work roll up to the next level within the team hierarchy.

SAFe® roles map to a hierarchy of teams

To support SAFe® teams, you reconfigure the default team as the Portfolio team to manage your epics. You then create subteams for program-level work and team-level work. Work can be tracked across teams and throughout each of the levels.

Stories, Features, Epics, Enablers, and Capabilities

All work and deliverables are captured in work items. Each work item is associated with a specific work item type with a predefined workflow. Each Azure Boards process provides support for specific work item types that you can use to track any of the SAFe® deliverables.

The work item types available to you're based on the process used when your project was created—Agile, Basic, Scrum, or CMMI—as illustrated in the following images.

The following image shows the hierarchy for the Agile process backlog work item:

Diagram that shows Agile work item types.

  • User Stories and tasks are used to track work.
  • Bugs track code defects.
  • Epics and features are used to group work under larger scenarios.

Each team can configure how they manage Bug work items at the same level as User Story or Task work items. Use the Working with bugs setting. For more information about using these work item types, see Agile process.

The items in your backlog may be called User Stories (Agile) Issues (Basic), Product backlog items (Scrum), or Requirements (CMMI). All four are similar: they describe the customer value to be delivered and the work to be completed.

You can track Enablers using User Stories or Features, and Capabilities using Features or Epics. Or, you if you have specific tracking and reporting needs, you can add custom work item types to track these types of deliverables. For more information, see Customize Azure Boards, Add custom work item types.

Work items provide support for the following tasks:

  • Add description and acceptance criteria
  • Assign to a team or area path and to a project member
  • Update status and assign to an iteration or sprint
  • Link work items, attach files, add tags
  • Add comments and view a discussion thread

Product and portfolio backlogs enable teams to quickly add and prioritize their User Stories, Features, and Epics. For more information about work items and work item types, see Track work with user stories, issues, bugs, features, and epics.

Team backlogs and boards

SAFe® backlogs map to team, program, and portfolio backlogs. Out of the box, the Agile process supports User Story, Feature, and Epic backlog levels. The hierarchical backlog structure shows work done to support Features and User Stories in the progress of an Epic.

Hierarchical backlog: epics, features, and stories

You can customize your backlog and boards, even adding portfolio backlogs, as described in Customize Azure Boards, Customize backlogs.

The board view of each backlog is configurable by each team.

Program Increments, releases, and sprints

SAFe® Release Trains, Releases, Iterations, Program Increments (PIs), and Sprints map easily to your iteration paths. By sharing iterations across the team hierarchy, you manage the releases in a cohesive manner.

SAFe® release trains map to iterations

Because epics can span several release trains, the Portfolio team isn't associated with any specific iterations. Program teams track their Feature deliverables, which ship with a PI. And Feature teams work in Sprints to complete several stories. Each team chooses which iterations support them to track their focused set of deliverables.

Teams track deliverables using iterations

Iteration goals and objectives

SAFe® practices include Agile release teams defining their iteration goals and objectives. We recommend using the project wiki or team dashboards to capture team information. The project wiki and team dashboards both support Markdown to add and format information.

For more information, see Share information later in this article.

Value streams and budgets

You can use tags for a quick and easy way to map Features and Epics to their Value Streams, Strategic Themes, and associated Budgets. You can add custom fields to capture budget estimates for Features that can then roll up to Epics.

Tags can track value streams or associated budgets

With tags that you add to work items, you can:

  • Filter any backlog or board
  • Create queries based on tags, and filter query results by tags
  • Create progress and trend charts or reports based on tags

For a more robust mapping of work to architecture or business features, you can specify the Value Area for each Epic, Feature, or Story.

Value Area tracks Business or Architectural work

With rollup, you can get Budget Estimates for Epics from a rollup of the estimates defined to their child Features, as shown in the following image.

Budget estimate rollup

To add custom fields, see Customize Azure Boards, Add a custom field.

Use the project wiki to support your portfolio vision and strategic themes

Information can be widely shared with an organization using the Azure DevOps project wiki. The wiki is a similar to a git repository that supports adding and editing pages using Markdown and a WYSIWYG editor. It versions each page so that it's easy to track who made changes and recover past versions.

Use your project wiki to support sharing the following SAFe® artifacts:

  • Portfolio Vision
  • Strategic Themes
  • Taxonomy
  • Goals
  • Objectives
  • Customer-centric practices

For more information about the project wiki, see Share information later in this article.

Milestones and key events

The end of each Program Increment, Sprint, Release Train, or Innovation and Planning (IP) Iteration represent natural SAFe® milestones. Many milestones are associated with specific ceremonies or practices, such as conducting retrospectives or demonstrating working software.

In Azure Boards, you can track other types of milestones or key events in the following ways.

  • Custom field, such as Milestone or Release field with predefined picklist
  • As a tag added to work items
  • As a work item that specifies a target date
  • As a one-day Iteration Path

With custom fields and tags, you can quickly filter backlogs, boards, and queries based on a specific milestone.

Shared services team structure

Resources that are shared across teams can be represented through their own Agile feature team, such as a UX Design team or a Security Compliance team. They can manage their backlog while having their work also appear in the backlogs of the teams they support.

Here we show how area paths are assigned to the UX Design team, and then selective subarea paths to other Agile teams. Work items that appear on shared area paths appear on the backlogs and boards of the associated teams.

Shared services area path and team structure

Retrospectives and reviews

To support teams doing retrospectives and reviews, we recommend using the Retrospectives extension by Microsoft DevLabs.

Retrospective board

This extension allows teams to create their own retrospective boards and capture the following tasks:

  • Collect feedback on project milestones
  • Organize and prioritize that feedback
  • Create and track actionable tasks to help each team in their improvement processes.

Share information

Azure Boards provides many ways to share information.

  • Work item forms provide rich-text fields to capture descriptions, acceptance criteria and more. File attachments can be added to work items or links to network file shares.
  • Project and team dashboards can be used to share information along with status and progress charts and widgets. For more information, see Add Markdown to a dashboard.
  • The Project wiki provides a central repository with versioning control built-in to share information with all project members. Other wikis can be created as needed. For more information, see About Wikis, READMEs, and Markdown.

For details on supported Markdown features, see the following articles.

Next steps

Culture and scale