Configure and customize Azure Boards

  • Artículo

TFS 2017 | TFS 2015 | TFS 2013

This article provides guidance to configure and customize Azure Boards. You should read this article if you are tasked with administrating a project for several teams and supporting the following business objectives:

  • Support portfolio management views
  • View calendar views to update status and progress
  • Track dependencies across teams or projects
  • Track time estimates or actual work completed

Note

This article applies to Azure DevOps Services. Most of the guidance is valid for both the cloud and on-premises versions. However, some of the features included in this article, such as Rollup, Analytics, and some portfolio planning tools, are only available for the cloud at this time.

If you're just getting started as a Project Administrator, see also Get started as an administrator.

What to consider?

When configuring or customizing work tracking tools, you'll want to consider the tools your teams use and how they will use them. Whether your teams follow Scrum, Kanban, or some combination of Scrumban, you can gain the most advantage of the Azure Boards tools by understanding the dependencies they have on configurations and customizations.

The primary items to consider as you structure your project are:

At a project level:

  • How many teams you want to define
  • How to structure area paths to support portfolio management views
  • Field customizations
  • Work item type customizations or custom work item types
  • Portfolio backlog customizations
  • Workflow customizations

At a team level:

  • How you'll use your product backlog to plan and prioritize your work
  • Whether you'll track bugs as requirements or as tasks, or not use bugs at all
  • Whether or not you'll use tasks to track time and capacity
  • How you'll use portfolio backlog levels
  • How you'll inform upper management of progress, status, and risks

Once you determine how you'll use the work tracking building blocks and tools, you'll want to make any necessary configurations and customizations to support your business and communicate to your teams how they should use the tools.

Work item types and portfolio backlogs

The first choice made in work tracking is the process selected when creating a project. For a comparison of each process, see Choose a process. Each process—Agile, Basic, Scrum, and CMMI—supports a set hierarchy of work item types. This hierarchy supports a product backlog and portfolio backlog(s).

The default work item types for each supported process are shown in the following tabs. Backlog work item types correspond to the Requirements category. Tasks correspond to the Task category.

The following image shows the Agile process backlog work item hierarchy. User Stories and Tasks are used to track work, Bugs track code defects, and Epics and Features are used to group work under larger scenarios.

Conceptual image, Agile work item type

Each team can configure how they manage Bugs—at the same level as User Stories or Tasks—by configuring the Working with bugs setting. To learn more about using these work item types, see Agile process.

You can add custom work item types at each level, and even add custom portfolio backlogs. Here, for example, is a project that added Objectives and Key Results as custom work item types and corresponding portfolio backlogs to the Scrum process.

Objectives and Key Results as additional portfolio backlogs

One of the main choices teams have is choosing the work item types they use to track their work. The following table summarizes the main options, recommended usage, and supported tasks and tools.

Work tracking options

Tasks and tools supported

Tasks only

Not recommended
There is no way to quickly enter new tasks in a backlog nor prioritize a backlog of tasks. In addition, there is no support for calendar views, cross-team views, or portfolio planning

Requirements with child-dependent tasks

Supports Scrum methods
Recommended for teams that follow Scrum methods and want to track time associated with work.

Many teams start out using Scrum methods to track and plan their work using 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, then adding child-dependent tasks is optional. Developers might add them simply as a checklist of items they need to complete a user story or backlog requirement.

Requirements only, such as user stories (Agile), issues (Basic), product backlog items (Scrum), requirements (CMMI)

Supports Kanban and Scrumban methods
Recommended for teams that follow Kanban or Scrumban methods, estimate work using Story Points, Effort, or Size, and don't track time associated with work.

Requirements grouped under portfolio work item types, such as epics and features

Supports calendar views, cross-team views, and portfolio planning
Recommended for organizations with several teams that want to view rollups and calendar views associated with multiple teams, and take advantage of all portfolio planning tools.

Configure and customization options

The following table indicates the areas you can configure and customize and the tools impacted by those customizations. Each area is customized either at the Organization, Project, or Team level as noted, or a combination of two. 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).

Configure or customize

Standard tools

Analytics

Portfolio planning tools

Area paths, project configuration, and team subscriptions (Project, Team)

  • Boards>All tools
  • Backlogs>All tools
  • Sprints>All tools
  • Cumulative flow diagram
  • Velocity
  • Burndown trend
  • Delivery plans
  • Feature timeline
  • Epic Roadmap
  • Portfolio plans (Beta)
  • Dependency Tracker

Iteration paths, project configuration, and team subscription (Project, Team)

  • Backlogs>Sprint planning
  • Sprints>Sprint backlogs
  • Sprints>Sprint capacity
  • Sprints>Taskboard
  • Velocity
  • Burndown trend
  • Delivery plans
  • Feature timeline
  • Epic Roadmap
  • Portfolio plans (Beta)
  • Dependency Tracker

Show bugs on backlogs & boards (Team)
Custom work item types, Product backlog (Process)
Custom work item types, Taskboard (Process)

  • Boards>Product board
  • Backlogs>Product backlog
  • Backlogs> Mapping tool
  • Sprints>Sprint backlogs
  • Sprints>Taskboard
  • Velocity

Custom work item types, Portfolio backlog (Process)
Additional portfolio backlogs (Process)

  • Boards>Portfolio boards
  • Backlogs>Portfolio backlogs
  • Backlogs> Mapping tool
  • Velocity

Custom workflow (Process)

  • Boards>Product board
  • Boards>Portfolio boards
  • Sprints>Taskboard
  • Cumulative flow diagram
  • Dependency Tracker

Custom field (Process)

  • Boards>Product board
  • Boards>Portfolio boards

Area paths, product teams, and portfolio management

Area paths are used 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 when you want to support a business hierarchy that wants to track progress of 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 as described early in this article. The two are not mutually exclusive. Note the distinctions between the two usages:

  • 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 determine 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. So when you structure your teams and projects, you want to make sure you understand how you'll use these grouping tools to support your business needs. Your choices impact the use of portfolio planning tools.

Area path-dependent tools

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

Tip

You can define your area path structure and assign area paths to teams. Or, you can add a team and create the area path with the team name at that time. If teams are fully independent, create a flat set of area paths. However, if you want to create a hierarchy of teams, then you'll want to create a tree-hierarchy of area paths. To learn more, see Configure a hierarchy of teams.

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

Area paths and team assignments

A default team and default area path are defined for each project. For small teams, a single team is sufficient to begin planning and tracking work. As organizations grow, however, it's useful to add teams to support their ability to manage their backlog and sprints.

Here is an example of area paths and their assignment to teams, which support portfolio management views for the Account Management and Service Delivery teams.

Area paths and team assignments

  • You create hierarchical area paths to support sub categories of features and product areas
  • To provide portfolio views, you assign two or more area paths and include sub-areas to a portfolio management team
  • Area paths assigned to a team determine what work items are filtered in a team view: product backlog, portfolio backlog, delivery plans, or other portfolio planning tool
  • Grouping work items under a parent feature or epic determine what rollup views are supported and how work appears in a calendar view such as Feature Timeline and Epic Roadmap

Prior to adding teams, we recommend you read the following articles:

Recommendations:

  • Consider what views upper management may want to view 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 will take two or more sprints to complete
  • 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

Tip

  • Work items can only be assigned to a single individual. So when defining work items, consider how many work items are needed to assign the work to those individuals who will be tasked to complete the work.
  • Choose the Node Name field as a column option to view the leaf area node in a backlog list or board card.
  • Don't create parent-child links among work items of the same type, such as story-story, bug-bug, task-task.

Most Azure Boards tools support a filtered view of work items based on area path and/or iteration path. Additional filters can also be applied based on keyword, assignment, work item type, and more.

Treat 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 like to track bugs as tasks performed in support of a requirement. The bugs then appear on their taskboard.

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

Talk with your team to determine how they want to manage bugs. Then change your team settings accordingly.

Tip

After you refresh a backlog or board and you don't see bugs where you expect them, review How backlogs and boards display hierarchical (nested) items. Only leaf nodes of nested items appear on sprint taskboards.

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.

Here we show Progress by all Work Items which displays progress bars for ascendant work items based on the percentage of descendant items that have been closed.

Progress bars showing rollup by work 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 are two weeks, three weeks, or a month long. To learn more about Iteration paths, see About area and iteration paths.

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

Iteration paths, grouped

Note

While Iteration Paths don't impact Kanban board tools, you can use Iteration Paths as a filter on boards. To learn more, see Filter your Kanban board.

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

Tip

If a team hasn't subscribed or selected an iteration path, that iteration path won't appear in a team view or tool.

Time tracking

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

However, some organizations require time tracking to support other purposes, such as for billing or maintaining time allocation records. Time values for estimated work and completed work are of interest. The Agile and CMMI processes provide these fields—Original Estimate, Completed Work, Remaining Work—for use in tracking time. You can use them for that purpose. However, Azure Boards provides limited native support for time tracking. Instead, you may want to consider using a Marketplace extension to support your additional time tracking requirements.

Note

The Original Estimate, Completed Work, Remaining Work fields were designed to support integration with Microsoft Project. Integration support with Microsoft Project is deprecated for Azure DevOps Server 2019 and later versions, including the cloud service.

Process changes that impact all teams

Any change made to a process applied to a project impacts all teams in that project. Many changes won't cause much disruption to the teams they support. However a few do, and those are described in this section.

Custom fields

Adding custom fields to a work item type doesn't impact any specific tool. The fields simply appear in the corresponding work items. If you add a custom numeric field, however, you can use it to support rollup on backlogs as well as the following reporting tools:

Note

All default and custom fields are shared across all projects in a collection or organization. There is a limit of 1024 fields that you can define for a process.

Custom work item types

When you make one or more of the following customizations, you impact the team tools as indicated.

  • Add a custom work item type to the Requirement category:
  • Add a custom work item type to the Task category:
  • Add a custom work item type to the Epic or Feature category:
  • Add a custom portfolio backlog level

When you add a custom work item type (WIT) to one of the following work tracking categories, you impact team tools in the following ways:

  • Task category:
    • 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
  • Requirement category:
    • Work items based on the new WIT appear on the product backlog and Kanban board
    • Each team must configure the Kanban board to support the new WIT
  • Epic or Feature category:
    • Work items based on the new WIT appear on the corresponding portfolio backlogs and Kanban boards
    • Each team must configure the Kanban boards to support the new WIT
    • The new WITs may 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 Kanban boards and sprint Taskboards.

Workflow states: User Story, Agile process

User Story workflow states, Agile process

Sometimes, teams want to track the status of their work that go beyond these default states. Support is provided for this in one of two ways:

  • Add custom workflow states to the work item type\
    • This option impacts all teams and requires that they update their Kanban board configuration
  • Add columns to a Kanban board
    • This option only impacts the team that adds the columns

Both workflow states and Kanban columns appear in the Cumulative Flow diagram for a team. Individuals can choose which columns appear in the chart.

Cumulative flow diagram

To learn more, see Cumulative flow diagram.

Who can make changes?

Because process-level, project-level and team-level settings can have a wide impact, changes are restricted to the following people who have the required permissions.

Process-level changes

To create, edit, or manage Inherited processes and apply them to projects, you must be a member of the Project Collection Administrators group. Or, you must have the corresponding permissions Create process, Delete process, Edit process, or Delete a field from organization set to Allow. See Set permissions and access for work tracking, Customize an inherited process.

For additional information, see the following articles:

Project-level changes

To add Area Paths or Iteration Paths, you must be a member of the Project Administrators group.

Or, to add, edit, and manage Area Paths or Iteration Paths under a specific node, you must have been granted one or more of the following permissions set to Allow:

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

For additional information, see the following articles:

Team-level changes

All team tools can be configured by a team administrator or a member of the Project Administrators group.

Team administrators are tasked with performing the following operations:

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

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

Try this next

Get started as an administrator