Troubleshoot reordering and nesting issues
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
When you reorder, nest, and display work items, Azure Boards 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:
Open your backlog.
Review the list of items to identify those items of the same type that are nested.
Example #1: The following image shows a user story as a child of another user story.
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.
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.
Refresh your backlog.
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:
- Open the work item listed in the error message.
- Look for a parent or child link. Make sure this link goes to a work item in the same category as the work item you opened. Look for a link that 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.
- 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 the following message:
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.
Open your backlog.
From the View options selector, choose to show or hide In Progress items.
Open your backlog.
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.
Hide In Progress items when you want to forecast work. For more information, see Forecast your product backlog.
Note
- For more information, see Configure your backlog view and Add custom work item types.
- For issues that might occur with multi-team ownership, see Exercising select features with shared area paths.
- To reorder work items on your backlog, you must have Basic or higher level access. If you have Stakeholder access, you can't reorder work items. For more information, see Stakeholder access quick reference.
Natural hierarchy for work item types
The following image shows the natural hierarchy for the Agile, Scrum, and Capability Maturity Model Integration (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 map work items to features. This mapping creates parent-child links in the background. For more information, see Organize your backlog.
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, create story-story, bug-bug, task-task, or issue-issue links. The backlog, board, and sprints experiences don't support reordering for same-category hierarchies, because that approach 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 to track bugs as requirements, tasks, or neither. See the following guidelines:
If you track bugs as requirements: Nest them only under the Feature level.
If you track bugs as tasks: Nest them only under the Requirement level.
For more information, see Show bugs on backlogs and boards.
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. 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
Only leaf nodes appear on sprint backlogs
Only leaf nodes appear on Taskboards
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.