Azure Boards FAQs

Members of an Azure Boards project can use most features for tracking work. Some features require a specific access level or security group membership. More limits can come from work-tracking permissions or custom rules. For details, see Default permissions and access for Azure Boards.

Use area path permissions to restrict who can view or modify work items. See:

• Set work tracking and plan permissions
• Grant or restrict permissions to select tasks

Yes. The browser caches conditional rules based on user or group membership. If you can't update a work item, you likely hit a cached rule. You can either wait for the client cache to expire (about three days) or clear it manually. To clear the cache, open the browser console and run:

window.indexedDB.deleteDatabase("wit")

Then refresh the page. For more information, see Rules and rule evaluation.

See Tools and clients that connect to Azure DevOps.

See About work items for an introduction.

Open a query and add these clauses:

• Work Item Type = [Any]
• State = [Any] Then add filters as needed. For more, see Create and save managed queries with the query editor.

No. Each work item can be assigned to only one user. You can assign only users listed in the people picker.

Group work by assigning it to the same area path. Area paths help organize work by product, feature, or business area and let teams focus on items assigned to their areas. You can also group work under a parent work item using parent-child links (a hierarchical grouping). For guidance, see Configuration and customization of Azure Boards, Area paths, product teams, and portfolio management.

Azure Boards doesn't use milestone markers for individual work items (Delivery Plans supports milestones). To indicate a milestone, you can:

• Add the word Milestone to the work item title
• Add a Milestone tag (Add tags to work items)
• Add a custom field labeled Milestone with a pick list (Customize process fields)
• Link work items to a milestone item (Link work items)
• Assign the milestone work item to the target sprint (Assign work to a sprint)

Link work items using Related, Predecessor/Successor, or other link types to track dependencies. See Link work items to other objects.

For cross-organization dependencies, consider the Dependency Tracker extension.

Each process defines default backlog levels (for example: requirement, feature, epic). Work item types assigned to those backlog levels naturally form parent-child relationships. For more information, see Organize your backlog, map child work items to parents. To customize backlogs, see Customize your backlogs or boards, Edit or rename the requirement backlog.

See Bulk modify work items, Bulk modify rich-text fields.

Yes. Configure two backlog-level rules:

1. Set the parent to Active when any child becomes Active.
2. Set the parent to Resolved or Closed when all children are Closed. For details, see Automate work item state transitions.

Administrators can configure backlog rules that automatically update work item states. For details and examples, see Automate work item state transitions.

Rules trigger when a child moves from New to Active or into Closed. They don't trigger when a child moves from Closed back to Active; this behavior is by design.

No. Rules apply to all work item types in a backlog level because rules use state categories (which are consistent across work item types).

Yes. Configure rules per backlog level. A rule on the user stories backlog doesn't affect features or epics. You can also configure separate rules for features and epics. See Automate work item state transitions.

Rules only trigger when both parent and child belong to the same team. This prevents rules from automatically affecting items owned by other teams. For details, see Automate work item state transitions.

Backlogs list work items; boards show those items as cards. Both use filters based on the team's area path and iteration path. For how the filtering works, see About teams and Agile tools, Team defaults referenced by backlogs and boards.

Add a team. Each team gets its own backlogs and boards and can customize them. See About teams and Agile tools.

Azure DevOps enforces limits such as the number of work items shown on a backlog or board and limits on teams. For a full list, see Work tracking, process, and project limits.

See Azure Boards migration and integration.

Each backlog shows work items filtered by the team's area and iteration paths and by work item type:

• Product backlog: Lists user stories (Agile), issues (Basic), product backlog items and bugs (Scrum), or requirements (CMMI). Offers options to show Parents, Forecast, and child items.
• Portfolio backlog: Lists Features (portfolio backlog) or Epics (epic backlog). Offers options to show Parents and child-item progress.
• Sprint backlog: Shows product backlog items assigned to the selected iteration and includes Work details options.

Yes. Assign sprints to work items and filter your board by iteration path. See Filter your board.

No. Task checklists only support the Task work item type.

Azure DevOps doesn't provide a native critical-path view. We recommend using Delivery Plans to view dependencies and a calendar of work. For more advanced critical-path analysis, consider connecting Azure DevOps to Microsoft Project or exploring Marketplace extensions. See Review team Delivery Plans and the Marketplace search for relevant extensions.

No. Team capacity isn't stored in the regular work-tracking data stores, so you can't roll it up the same way you roll up numeric work item fields.

No. Column width isn't configurable. To request this feature, upvote it on our Developer Community page.

Yes. Use board-related fields to query column changes. See Query by assignment or workflow changes, board change queries.

Yes. Install the Query Based Boards Marketplace extension.

Yes. Use the Azure Boards Kanban Tools Marketplace extension to copy board configuration across teams.

Yes. Track column moves using the Board Column and Board Column Done fields.

This error usually means the workflow states for work item types in the Requirement category aren't mapped to columns. Select Correct this now in the error dialog to open Settings and map states to columns.

After you map each state to an existing or new column, the board displays items assigned to those states.

Yes. You can add or remove swimlanes and configure swimlane rules to move work items automatically when conditions are met. For more information, see Add or remove swimlanes and set up swimlane rules.

Define work item templates for teams you belong to. To create templates and set defaults for fields, see Use templates to add and update work items.

The product doesn't support setting a default template for a team at this time.

No. The product doesn't support copying templates between teams or projects.

You can't create hierarchy templates that set a default parent. To create linked child items, consider using Excel to bulk add items and set parent-child links, or add child items from a board. See:

• Add task checklists
• Add, run, and update inline tests
• Add features and epics

On the work item type page, open the actions menu ( ) for the template you want to remove and choose Delete.

See Azure Boards & GitHub.

No. You can't set the work item status automatically when linking a commit or pull request.

You configure and customize Azure Boards at the project and team level. For an overview, see Configuration and customization of Azure Boards.

For other FAQs about configuration and customization, see Azure Boards Configuration and Customization FAQs.

Related content

• Query FAQs
• Work tracking, process, and project limits
• Azure Boards Configuration and Customization FAQs
• FAQs: Work in Excel connected to Azure Boards
• Work across projects FAQs
• Azure Boards extensions
• About teams and Agile tools