Fix reordering and nesting issues

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

When you reorder, nest, and display work items, Azure DevOps expects a natural hierarchy. The natural hierarchy breaks when you create same-category or same-type links between work items. For example, parent to child links that are bug to bug or user story to user story or requirements category to task category. Use this article to address error messages when you add links that aren't in the natural hierarchy.

"You cannot reorder work items and some work items might not be shown"

You might see an error similar to one of the following messages:

  • You cannot reorder work items and some work items might not be shown
  • No work item IDs are listed

To address this error, do the following steps:

  1. Open your backlog.

  2. Review the list of items to identify those of the same type that are nested.

    • Example #1: The following image shows a user story as a child of another user story.

    Screenshot showing nested user stories on a backlog.

    • Example #2: The following image shows a bug as a child of a user story. When the backlog displays user stories and bugs at the same level (Requirements category), it results in a nested item that disables the ordering feature.

    Screenshot of nested user story and bug.

  3. Remove any parent-child links that exist among nested items of the same work item type or category, or consider changing the link type to 'Related.'

  4. Refresh your backlog.

Following these steps should resolve the issue, and the error message no longer displays.

"Work item can't be reordered because its parent is on the same category"

You might see an error similar to one of the following messages:

  • You cannot reorder work items and some work items might not be shown. See work item(s) 7 to either remove the parent to child link or change the link type to Related.
  • Work item 3 can't be reordered because its parent is on the same category.

To address this error, do the following steps:

  1. Open the work item listed in the error message.
  2. Look for a parent or child link. Make sure this link goes to a work item within the same category as the work item you opened. This link goes to another work item that appears on the same backlog level as the work item you opened. Depending on your team's bug behavior setting, bugs might appear with requirements or tasks.
  3. Remove the problem parent-child link. If you would like to keep these items associated, use 'Related' link type instead.

The message no longer displays.

"Work items in progress might disappear on refresh"

You might see an error similar to one of the following messages:

Items added to the backlog might disappear on a refresh because your team project marks them as "in progress". Those items appear when you change the "In progress" filter to Show.

This message indicates that the In Progress filter for the backlog is turned off.

When you refresh your browser, the work items display based on your selected filters. To reset the filters, do the following steps.

  1. Open your backlog.
  2. From the View options selector, choose to show or hide In Progress items.
  • If you turn the In Progress control off, then items that are in the Active, Committed, or Resolved states or states that map to the In Progress category state don't appear.

Screenshot of View options selector, In progress control, version 2020 and later.

Screenshot of View options selector, In progress control, version 2019.

Note

Natural hierarchy for work item types

The following image shows the natural hierarchy for the Agile, Scrum, and Capability Maturity Model Integration (CMMI) processes.

Conceptual image of natural hierarchy for the Agile, Scrum, and CMMI processes.

Best practices

Do:

  • Maintain a flat list, rather than nesting requirements, bugs, and tasks.
  • Only create parent-child links one level deep between items that belong to a different category. The category a work item belongs to gets determined by your process levels and your team's selected bug behavior.
  • Use the feature work item type to group user stories (Agile), issues (Basic), work items (Scrum), or requirements (CMMI). You can quickly map work items to features, which creates parent-child links in the background.

Don't:

  • Create a hierarchy of work items, tasks, and bugs.
  • Establish same-category hierarchies, such as parent-child links among work items of the same type (for example, story-story, bug-bug, task-task, or issue-issue). The backlog, board, and sprints experiences don't support reordering for same-category hierarchies, as it introduces confusion by ordering a work item that doesn't belong at that level.

Track bugs as requirements or tasks

Each team has the flexibility to choose how to track bugs—whether as requirements, tasks, or neither. See the following guidelines:

  • If you track bugs as requirements: Nest them only under the Feature level.

    Screenshot of linked bugs like requirements.

  • If you track bugs as tasks: Nest them only under the Requirement level.

    Screenshot of linked bugs like tasks, underneath the Requirement level.

Display nested items on backlogs and boards

Sprint backlogs and Taskboards exclusively display the last node in a same-category hierarchy, which is referred to as the leaf node.

Sprint backlogs and Taskboards

When tasks and bugs link to their parent requirements, they group them correctly on the sprint backlog and Taskboard. But, when you establish parent-child links between a requirement and a bug, and between the bug and a task, as demonstrated here, the task appears on the sprint backlog and Taskboard, while the bug doesn't.

Hierarchy of items assigned to a sprint backlog

Screenshot of Sprint backlog query with linked bug and task.

Only leaf nodes appear on sprint backlogs

Screenshot of Sprint backlog with leaf node task.

Only leaf nodes appear on Taskboards

Screenshot of Sprint board with leaf node task.

Frequently asked questions (FAQs)

Q: Is there a workaround to display intermediate nodes within a hierarchy?

A: No, not at this time. You can always check the entire list of items assigned to a sprint when you select Create query.