Azure DevOps, formerly known as Visual Studio Team Services (VSTS), does not enforce strict rules on all backlogs.
The good side is that teams have the autonomy and flexibility to follow a process that meets their needs. The dark side is that it allows the teams to follow practices that may have unexpected side effects, such as ghost (hidden) work items.
Let me demonstrate one the unexpected side effect using a very simple backlog.
We have discussed this topic before. See the hunt for stealth tasks … what happened to my task on the TFS task board? , dated 2013.
Using the Agile process, we create a simple product backlog with five User Stories. Note that there is a nested Task under User Story #2. So far so good.
We nest User Stories #3 and #5 under User Story #2. We now have a Product Backlog with same-level nested work items, which we can re-order to meet the higher-level goals.
When we switch to the Sprint Backlog the product disables ordering as the backlog contains nested items. The experience between the Product and the Sprint Backlogs are different, which may be confusing, but we still see all the User Stories.
Next we delete the nested Task in User Story #2. The resulting Sprint Backlog as expected ...
… until we refresh the page. User Story #2 is gone.
Goodbye User Story #2 and welcome ghost!
It's still there! We can visually see three User Stories, while the planning pane confirms that there are still four (4) User Stories.
To cut a long story short …
You can use Work Item queries to bubble up the ghosted work items, or you encourage your teams to steer away from same-level nested backlogs. I vote for the latter until a process and its rules are enforced consistently across the product.
If you agree this is an issue, please vote on this UserVoice idea.