Edit

Share via

Configure and customize Azure Boards

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022 | Azure DevOps Server 2020

Customize Azure Boards to match your team's processes and portfolio needs. This article describes recommended tasks and considerations for administrators who configure area/iteration structure, work item types (WITs), workflows, and board behavior.

If you already know the configuration tasks you want, start with these articles:

Note

Most guidance here applies to both cloud and on-premises deployments. Some features (for example, Rollup, Analytics, and portfolio planning tools) are cloud-only.

Key considerations

Before you change settings, decide how teams will work and what management needs to see. Consider:

  • Project vs. team structure: How many teams, area path hierarchy, and rollup views do you need?
  • Iterations: Sprint cadence, release grouping, and forecast horizon.
  • Work item scheme: Which WITs will teams use (Features, Stories/Issues/PBIs, Tasks, Epics)?
  • Reporting needs: Which fields, rollups, and analytics views must be available?
  • Customizations: Custom fields, workflows, and WITs affect boards, backlogs, and reports.
  • Permissions and governance: Who can change processes, area/iteration trees, and team settings?

Document your choices so teams apply them consistently.

Work item types and portfolio backlogs

Choose a process (Agile, Basic, Scrum, or CMMI) when you create a project. Each process defines a default set of WITs and portfolio/backlog levels. You can add custom WITs and portfolio backlogs to support your organization.

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.

Use custom WITs and portfolio backlogs when you need additional planning layers (for example, Objectives and Key Results).

Screenshot showing a project that adds Objectives and Key Results as custom portfolio backlogs.

Pick one of these high-level tracking approaches based on team practices:

  • Tasks only — Not recommended. Offers limited prioritization and no portfolio planning.
  • Requirements with child tasks — Good for Scrum teams that estimate and track time.
  • Requirements only — Good for Kanban or Scrumban teams that don't track time.
  • Requirements grouped under portfolio WITs — Use when multiple teams need rollups and cross-team calendars.

Explain the chosen approach to teams and update process documentation.

Areas, iterations, and team setup

Use area paths to partition work by product, feature, or business area. Use iteration paths for sprints, releases, or milestones.

Recommendations:

  • Create area path hierarchies that reflect how managers want rollups reported.
  • Give each team a default area and iteration subscription so work items inherit correct context.
  • Use consistent iteration cadences across teams that deliver together.

Screenshot showing area paths and team assignments.

Related content:

Show bugs on boards & backlogs

Each team decides whether bugs appear on the product backlog (as requirements) or are tracked as tasks tied to requirements. Teams that use Scrum often show bugs on the backlog; teams using Agile or CMMI can choose whether bugs appear on backlogs. To change how bugs display for a team, update the team settings:

Keep a consistent team policy so queries, boards, and rollups behave predictably.

Rollup and portfolio views

Add rollup columns to backlogs to show progress bars, counts, or sums for child items. Use Delivery Plans and feature timelines to view cross-team schedules and dependencies.

Screenshot showing progress rollup bars on a backlog.

For cross-team planning, use Delivery Plans and the Feature timeline extensions where appropriate.

Boards, columns, and workflows

Work item workflow states determine default board columns. You can:

  • Add custom workflow states to WITs (affects all teams).
  • Add columns to team boards (affects only that team).
  • Map state-to-column mappings carefully to preserve reporting consistency (for example, cumulative flow diagrams).

Related content:

Custom fields and reporting

Custom fields let you capture project-specific data. They can power rollups and reports but apply across the process.

Recommendations:

  • Limit custom fields to those that support reporting or automation.
  • Use numeric custom fields for rollup sums; use picklists for consistent reporting.
  • Remember: process-level fields are shared across projects in the collection/organization.

Note

You can define up to 1,024 fields per process.

Custom WITs and process changes

Adding or modifying WITs and workflows affects many tools:

  • New requirement-level WITs appear on product backlogs and may appear on sprint backlogs.
  • New task-level WITs appear on taskboards.
  • Teams must update boards and mappings to display custom WITs.

Process-level changes affect all teams. Limit disruptive changes and communicate them in advance.

Permissions and who can change what

Control who changes processes, area/iteration trees, and team configuration:

  • Process-level changes: Project Collection Administrators or users with appropriate process permissions.
  • Project-level changes (areas/iterations): Project Administrators or users with node permissions.
  • Team-level changes: Team administrators or Project Administrators.

Related content:

Time tracking and sprint planning

Use Remaining Work, Original Estimate, and Completed Work fields for sprint planning and capacity. If you track time for billing or other purposes, evaluate Marketplace extensions for richer time-tracking support.

Related content:

Practical checklist for admins

  • Decide process and WIT strategy (inherit or customize).
  • Design area and iteration hierarchies.
  • Configure teams and set default area/iteration subscriptions.
  • Create necessary shared query folders and permissions.
  • Add rollup columns and dashboard widgets that execs need.
  • Pilot changes with one team before applying wide-scope updates.
  • Communicate changes and update your project wiki.

Related content