Делите путем


Customize Azure Boards to support SAFe® practices

TFS 2017 | TFS 2015 | TFS 2013

The main reason to customize your process is to support tracking and monitoring progress, reporting on key metrics, and meeting specific business requirements. In this article, you'll learn about select process customizations you can make and why you might want to make them support your Scaled Agile Framework (SAFe®) practices. Most of these customizations are optional.

Specifically, you'll learn how Azure Boards supports SAFe® practices through the following operations.

  • Customize work item types or add custom work item types
  • Add a custom field or customizing existing fields
  • Customize the workflow
  • Add custom rules to a work item type
  • Add custom controls or custom extensions
  • Customize your backlogs or add a custom portfolio backlog

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.

About customization and the inherited process

Azure Boards provides a graphical user interface to support customization of your projects. This feature is called the Inherited process. All projects that use an inherited process are automatically updated when customizations are made to that process.
For an overview of all the customizations you can make to an inherited process, see About process customization and inherited processes.

Customize work item types

Each work item type defines the fields that capture and store information. You can customize existing work item types in the following ways to support specific SAFe® tracking requirements.

For details on customizing a work item type, see Add and manage work item types.

Add a custom field

You add a custom field to support tracking data requirements that aren't met with the existing set of fields. Some fields to consider adding to one or more work item types include those items listed in the following table.

Field name

Work Item Types

Notes

Budget cost

Feature, Epic

Use to capture estimated costs. Can use rollup to capture the total estimated cost of an Epic's Features.

Category or Group

Feature, Epic, User Story

Use to specify a picklist to indicate the work item is cataloged as one of the following SAFe® categories: Feature, Capability, Enabler, or Solution.

Milestone

Feature, Epic, User Story

Use to specify a picklist of Milestone of Events which a story, feature, or epic should meet.

Value Stream

Feature, Epic, User Story

Use to specify a picklist to support a taxonomy of value streams you want to associate with work.

For details on adding a custom field, see Add a custom field to a work item type.

Field versus tags usage

You can capture a value stream using a field or tags. Tags represent a more informal and adhoc method for categorizing work. A specific field, particularly one with preset items, is more formal. When determining how you want to use tags and fields, consider the following statements:

  • You can make a field required through custom rules, however, you can't require tags be added to a work item.
  • You can create query charts based on custom fields, however, you can't specify a tag for use in query charts.
  • You can filter backlogs, boards, and queries based on fields or tags.
  • The number of tags created can quickly grow as anyone can add new tags as long as they have the correct permissions.

Customize existing fields

You customize existing fields to support one or more of the following actions:

  • Relabel the name of the field.
  • Change where the field appears on the work item form or remove it from the form.
  • Add or change a picklist (drop-down menu). For example, the Value Area provides two options, Business and Architectural. You can add to this picklist of values.
  • Change the default assignment made to a field.
  • Make a field required.
  • Add a rule to a field as described in the next section.

For an index of existing fields, see Work item field index. For details on customizing a field, see Add and manage fields for an inherited process.

Add rules to a field

Field rules provide support for many business use cases. Rules specify an action to take based on a selected condition. For example, you can make a field required based on the value assigned to another field. You can add several rules to a field.

The following images show the supported conditions and actions you can select from.

For details on setting field rules, see Add a rule to a work item type (Inheritance process).

Customize the workflow

You may want to customize the workflow for User Stories, Features, and Epics so that it matches your workflow process. By customizing the workflow early, you minimize the Kanban board configuration teams must do.

The default workflow for the Agile process includes New, Active, Resolved, and Closed states. While each team can add workflow columns to their Kanban board, you might want to customize the workflow to track these columns instead. That way the Kanban boards for all teams are set up to use the same workflow states.

For example, you can add and rename workflow States to match the Kanban columns shown in the following image—Backlog, Analyze, Develop, Test, and Done.

Kanban board columns to visualize flow and limit WIP

Review with your team's what workflow states will most support their Agile practices. For more details, review the following articles:

Custom controls

With custom controls, you can add rich functionality to a work item form. A custom control is an extension that's been added to the Marketplace Extensions for Azure DevOps.

You can add controls from the Marketplace or create your own.

  • WorkBoard OKRs Integrates WorkBoard helps organizations align, localize, and measure Objectives and Key Results (OKRs) across the business. With this integration, teams can view and update their OKRs from within Azure DevOps.

Add custom work item types

The User Story, Feature, and Epic work item types are meant to support product planning and tracking. However, other work item types might be useful to support your SAFe® organization's customer-centric focus. Specifically, you might want to add work items to capture customer feedback, customer requests, and more.

When defining a new work item type, think through the following items:

  • Information you want to capture, track, and report on
  • How work will be captured
  • The workflow to support tracking the work

To keep things simple, however, it's always best to minimize the amount of customizations you make. So, if you can get by with existing work item types, you might consider adding custom field(s) as needed to track specific information.

Customize your backlogs

Each team's backlog and board is designed to support specific work item types. For the Agile process, the work item types are as listed.

  • Agile Release Teams: User Stories and, optionally, Bugs
  • Program Teams: Features
  • Portfolio Teams: Epics

However, you can add other work item types, existing or custom, to these backlogs. Each team can subscribe to the set of backlogs that they need to track.

You can also add up to three more portfolio backlogs as shown in the following illustration. Portfolio backlogs are designed to be hierarchical. For SAFe, you may want to add a Solution Backlog that appears as a parent to the Epic backlog.

Additional portfolio backlogs

For details on customizing backlogs, see Customize your backlogs or boards (Inheritance process).

Add even more functionality

You add the following Marketplace extensions to get access to many rich features that support SAFe.

Try this next

Before customizing your project, we recommend you read the Configure and customize Azure Boards. It provides detailed information on administrating a project for several teams and supporting various business objectives.

See also: