Configure and customize Azure Boards

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

Azure Boards can be configured and customized in various ways to support different scenarios and requirements. This article describes recommended tasks for customizing Azure Boards to best manage your specific portfolio, dependencies, and monitoring needs. The presented guidance is especially suited for administrators responsible for managing multi-team projects. If you're new to project administration, you might read Get started as an administrator before you start on specific tasks.

If you know which tasks you want to complete, you can get started quickly with the following articles:

• Customize cards
• Manage columns
• Expedite work with swimlanes
• Configure your backlog

Considerations for customization

To make the most of Azure Boards, you need to know how your teams use their tools and functions (for example, Scrum, Kanban, and Scrumban). Understand your team's requirements and any tool dependencies. Keep these considerations in mind as you make configuration adjustments and customizations.

The following table summarizes the primary considerations for structuring your Azure Boards project:

Customize your work tracking building blocks and tools to best support your business needs and communicate the usage guidelines to your team.

Work item types and portfolio backlogs

When you create a project in Azure Boards, you first select a process. Each process type supports a hierarchy of WITs, including product and portfolio backlogs. The four process types are Agile, Basic, Scrum, and Capability Maturity Model Integration (CMMI). Default WITs for each process are listed in corresponding tabs, with backlogs under Requirements and tasks under Task.

You can add custom WITs at each level, and even add custom portfolio backlogs. The following image shows an example project that adds Objectives and Key Results as custom WITs and corresponding portfolio backlogs to the Scrum process:

Work tracking options and recommended usage

Teams can choose which WITs they use to track their work. This article describes four options:

The following sections describe the recommended usage for each option, along with supported tasks and tools.

Tasks only

Tracking tasks only is not recommended. There's no way to quickly enter new tasks in a backlog or prioritize a backlog of tasks. Calendar views, cross-team views, and portfolio planning aren't supported when you track only the tasks.

Requirements with child-dependent tasks

Tracking requirements along with child-dependent tasks is recommended for teams that use the Scrum process and track time associated with work.

Consider this tracking option for the following scenarios:

• Quickly define and prioritize product backlog items
• Forecast sprints by using team velocity metrics
• Plan sprints with the Backlog Planning tool
• Plan and track capacity with the Sprint capacity tool
• Track estimated and remaining work by using a Taskboard
• Monitor Sprint burndown based on remaining work, such as hours or days:
• Conduct daily scrums, update, and monitor task status by using a Sprint Taskboard
• Estimate work by defining Story Points, Effort, or Size
• View progress bars, counts, or sums of rollup on tasks
• Track dependencies across teams and projects with delivery plans

Many teams start out using Scrum methods to track and plan their work with the tools available through the Sprints hub. The Sprints tools support estimating and tracking remaining work and use of capacity planning. If you don't plan on using these tools, adding the child-dependent tasks is optional. Developers might add them as a checklist of items for completing a user story or backlog requirement.

Requirements only

Tracking the requirements only is recommended for teams that follow Kanban or Scrumban methods. You can track requirements for user stories (Agile), issues (Basic), product backlog items (Scrum), and other data (CMMI).

Consider this option for the following scenarios:

• Quickly define and prioritize product backlog items
• Plan sprints with the Backlog Planning tool
• Estimate work by defining Story Points, Effort, or Size
• Forecast sprints by using team velocity metrics
• Monitor Sprint burndown based on requirement estimates
• Update requirement status by using a Kanban board
• Track dependencies across teams and projects with delivery plans

Requirements grouped under portfolio WITs

Tracking requirements grouped under portfolio WITs, such as epics and features, is recommended for organizations with multiple teams that want to view rollups and calendar views for other teams. This approach allows organizations and teams to take advantage of all portfolio planning tools.

Consider this option for the following scenarios:

• Quickly define and prioritize portfolio backlog items
• Quickly define child user stories of portfolio checklist items
• Map work items to features and epics with the Mapping tool
• Support cross-team progress calendar views by setting up delivery plans
• Support calendar view of all team features by setting up a feature timeline
• Support calendar view of a specific epic on an epic roadmap
• View progress bars, counts, or sums of rollup on child items
• Track dependencies across teams and projects with delivery plans

Options to configure and customize

The following sections describe the areas you can configure and customize and the tools impacted by customizations. You can customize each area at the Organization, Project, or Team level, or a combination of two levels, as indicated. For a description of the Standard tools, Analytics tools, and Portfolio planning tools, see What is Azure Boards, In-context reports: Work tracking, and Plans (Agile at scale).

Area paths, product teams, and portfolio management

Use area paths to group work items by product, feature, or business areas and to support teams responsible for work assigned to those areas. You can define a hierarchical set of area paths or a flat set. Typically, you define a hierarchical set of area paths to support a business hierarchy that wants to track progress for several teams.

Area paths and hierarchical grouping

The two main ways to group work items are by area path and by parenting them under a portfolio work item type (WIT), as described earlier. The two methods aren't mutually exclusive and have some differences:

• Area paths assigned to a team determine what work items appear in a team view: product backlog, portfolio backlog, delivery plans, or other portfolio planning tool.
• Grouping work items under a parent feature or epic determines what rollup views are supported and how work appears in a portfolio planning tool.

You can also assign tags to work items to group them for query and filter purposes. When you structure your teams and projects, make sure you understand how you plan to use the grouping tools to support your business needs. Your choices affect the use of portfolio planning tools.

Area path-dependent tools

To perform the following tasks, you must define area paths:

• Query and chart work items based on area paths
• Assign work to more than one team
• Work with management and feature teams
• Filter a backlog, query, board, or plan by using area paths

To use the following tools, teams must subscribe to area paths:

• Boards > all tools
• Backlogs > all tools
• Sprints > all tools
• Delivery plans
• Rollup
• Analytics > all tools

Area paths and team assignments

Each project has a default team and default area path. In some cases, there's only one team to plan for and track work. As an organization grows, you might add more teams to manage the backlog and sprints.

The following example shows area paths and their assignments to teams, which support portfolio management views for the Account Management and Service Delivery teams.

For more information, see the following articles:

• Explore portfolio management
• Understand area paths
• Explore teams and Agile tools
• Promote an Agile culture

Recommendations

Review the following recommendations for using area paths and hierarchical grouping:

• Consider what upper management needs to know and how to best support them
• Consider how you want to use rollup both for a team and portfolio management
• Define epics and scenarios for large initiatives that take two or more sprints to complete
• Create hierarchical area paths to support subcategories of features and product areas
• Define requirements for work that can be accomplished in a single sprint and can be assigned to a single individual
• Define tasks to track more granular details or when you want to track time spent working

Most Azure Boards tools support a filtered view of work items based on area path or iteration path. You can also apply more filters based on keyword, assignment, WIT, and more.

Bugs as requirements or tasks

Each team can choose how they want to manage bugs. Some teams like to track bugs along with requirements on the backlog. Other teams prefer to track bugs as tasks performed in support of a requirement. Tracked bugs appear on the team Taskboard.

If you use the Scrum process, your default setup is to track bugs along with product backlog items. If you work in a project based on the Agile or CMMI process, bugs don't automatically appear on your backlog.

Determine with your team how you want to manage bugs, then change your team settings accordingly.

Rollup, hierarchy, and portfolio management

Rollup columns allow you to view progress bars or totals of numeric fields or descendant items within a hierarchy. Descendant items correspond to all child items within the hierarchy. You can add one or more rollup columns to a product or portfolio backlog.

The following image shows Progress by all Work Items, which displays progress bars for ascendant work items based on the percentage of closed descendant items:

Iteration paths - sprints releases and versioning

Iteration paths support Scrum and Scrumban processes where work is assigned to a set time period. Iteration paths allow you to group work into sprints, milestones, or other event-specific or time-related period. Each iteration or sprint corresponds to a regular time interval referred to as a sprint cadence. Typical sprint cadences include two weeks, three weeks, or a month. For more information, see About area and iteration paths.

Iteration paths can be a flat list, or grouped under release milestones as shown in the following image:

While iteration paths don't affect board tools, you can use Iteration Paths as a filter on boards. For more information, see Filter your board.

Define iteration paths and assign them to teams when you want to use the following tools:

• Assign work items to sprints by using the Planning pane
• Chart work items based on Iteration Path
• Forecast product backlog
• Implement Scrum practices (all tools) for your team
• Use Delivery Plans and calendar views
• Chart team velocity and Chart Sprint burndown

Time tracking

Most organizations that follow Scrum processes use time estimates for Sprint capacity planning. Azure Boards tools fully support tracking time for this purpose. The primary field for tracking time is Remaining Work, which typically zeros out at the end of the sprint.

Some organizations require time tracking to support other purposes, such as billing or maintaining time allocation records. Time values for estimated work and completed work are of interest. The Agile and CMMI processes provide several fields to support time tracking: Original Estimate, Completed Work, and Remaining Work.

Limitations

• Azure Boards provides limited native support for time tracking. To support your other time tracking requirements, consider using a Marketplace extension.

Process changes that affect all teams

Any modification made to a process in a project affects all teams in that project. Many modifications don't cause significant disruptions. Certain changes can require critical adjustments for the teams, as described in the following sections.

Custom fields

When you add custom fields to a WIT, it doesn’t directly affect any specific tool. Instead, these fields become visible within the corresponding work items. For instance, if you introduce a custom numeric field, you can utilize it for rollup calculations on backlogs. Also, you can use the custom field with the following reporting tools. Although the effect isn't tool-specific, it does enhance your ability to tailor work items to your project's needs.

• In-context Velocity report and dashboard widget
• In-context Sprint Burndown report and dashboard widget
• Dashboard Burndown and Burnup widget

Custom WITs

When you add a custom WIT to a specific category, the following changes occur.

Task-level changes:

• Child work items of the new WIT appear on the product backlog
• Work items based on the new WIT appear on the sprint backlogs and Taskboards

Requirements changes:

• Work items based on the new WIT appear on the product backlog and \board
• Each team must configure the \board to support the new WIT

Changes to epics or features:

• Work items based on the new WIT appear on the corresponding portfolio backlogs and boards
• Each team must configure the \boards to support the new WIT
• The new WITs might not appear on one or more of the portfolio planning tools

Custom workflow

Each process supports a default workflow. This workflow defines the default columns that appear on the boards and sprint Taskboards.

Some teams want to track the status of their work beyond the default states. The following support is available:

• Add custom workflow states to the WIT. All teams are affected. Each team must update their board configuration.

• Add columns to a board. Only teams that add the columns are affected. For more information, see Manage columns in a work item list in Azure Boards

Both workflow states and columns appear in the Cumulative Flow diagram for a team. Individuals can choose which columns appear in the chart. For more information, see View and configure a cumulative flow diagram.

Who can make changes?

Process-level, project-level, and team-level settings can have a wide effect. The ability to make changes is restricted to users with specific required permissions, as described in the following sections.

Process-level changes

To create, edit, or manage Inherited processes and apply them to projects, the user must be a member of the Project Collection Administrators group.

As an alternative, the user must have one or more of the following permissions set to Allow:

• Create process
• Delete process
• Edit process
• Delete field from organization or account

These permissions are described in Set permissions and access for work tracking - Customize an inherited process. The following articles provide more information:

• Explore the Inheritance process model
• Customize a project
• Create and manage a process

Project-level changes

To add area paths or iteration paths, the user must be a member of the Project Administrators group.

As an alternative, to add, edit, and manage area paths or iteration paths under a specific node, the user must have one or more of the following permissions set to Allow:

• Create child nodes
• Delete this node
• Edit this node
• View permissions in this node

The following articles provide more information:

• Define area paths and assign to a team
• Define iteration paths (sprints) and configure team iterations

Team-level changes

To configure team tools, the use must be a team administrator or a member of the Project Administrators group.

Team administrators have permission to complete the following operations:

• Add team members
• Subscribe to area and iteration paths
• Configure backlogs and other common team settings
• Configure boards
• Manage team notifications

For more information on configuring backlogs and boards, see Manage and configure team tools.

Related content

• Get started managing your project
• Manage and configure team tools
• Review the Azure Boards FAQs for configuration and customization