Docs › Get a board

Board another level of the same query

A named board of backlog items carries a Level selector in its toolbar, reading the level it boards under your process's own name: Epics, Features, Backlog items, or whatever your process calls them, custom levels included. It appears when your process has more than one backlog level to choose from. A query opened on the Board tab of its results page has no selector: it always boards the level its query returns.

Pick a different level and the board does not re-run its query against that level. It boards the relatives of the work the query already found.

The rule, in one sentence

Your query defines a population once, with whatever criteria you put in it. The level selector chooses which level of that population's family you are looking at.

• A level above shows the nearest parent of each item the query returned, at that level. A backlog item parented directly by an Epic appears on the Epic level, so a missing Feature skips a rung rather than losing the item.
• A level below shows the children of the query's items at that level, including children the query returned itself. A board of Features on a tree query that also returns their backlog items, switched to the Backlog items level, shows those backlog items. A backlog item the query returned that sits under none of its other items is not one of their children, so it does not appear there.
• Back on the board's own level, the cards are the query result again, exactly as before.

Your query is never rewritten. Open it in Azure DevOps after switching levels and you will find the text you wrote, unchanged.

Why it is not "the same query, one level up"

Because there is no such thing. The criteria in a query are facts about the level you wrote them for. "Backlog items assigned to me, in this sprint, tagged risk" has no meaning as a sentence about Features: features are not assigned to a person, they outlive a sprint, and the tag is on the story. A product that quietly swapped the type and kept the rest would be asking a different question under the name you gave the first one, and, more often than not, returning nothing at all.

So the criteria stay where they work, on the level you wrote them for, and the other levels answer a question that is well posed: who does this work belong to, and what is it made of?

What follows from that

A parent with no matching child does not appear. If your query is "backlog items tagged risk" and a Feature has no such item under it, that Feature is not on the Features level of this board. This is the same promise as before, one level up: the board shows the work your query is about, and nothing else.

Two consequences worth expecting:

• A level above is usually a much shorter board. Fifty tagged stories under eight features make eight cards. That is the point: it is a view of who carries the work, not a second copy of it.
• It is not a way to see a whole level. If you want every Feature in a project on a board, give that board a query for Features. An ordinary query makes an ordinary board, and that board looks exactly like the native one.

Adding items is switched off while you are on another level. A new item would be created at the level you are looking at, which your board's query does not return, so it would appear once and disappear on the next refresh. Add the item on the board's own level, or from Azure DevOps. Adding a child from a card is unaffected: that is decomposition, and it belongs to the card it hangs from.

Dragging to reorder is switched off too, even on a board where you have turned on Reorder from this board. What you are looking at is the part of a level that has matching work under it, so dropping a card between two others would decide its position among items you cannot see.

Switching levels resets the columns. A configured column names states of the level it was built for, so a switch drops the board's configured columns, their order, split columns, WIP limits and definitions of done, and the new level gets one column per state. The change is saved on the board, so everyone who opens it sees the same thing, and coming back to the board's own level does not restore them. Style rules, swimlanes and card fields are kept. For the same reason, on a shared board the selector switches levels only for someone who can change the board: the person who created it or a project administrator, and on a board in a team's group, that team's administrators too. Anyone else who opens it is told who can, and the board stays where it is (see Who can change a board).

A snapshot shows the board's own level. Set an as-of date and the board returns to the level its query returns, with a note saying so: a past population's parents would have to be worked out from today's hierarchy, which would put yesterday's date on a shape that never existed.

Showing what nobody has broken down yet

Pure ancestry can never reach a Feature with nothing under it: there is nothing beneath it to match your query. Sometimes that is exactly the item you want to see: the work that has been asked for and not yet decomposed.

While the board is showing a level above its own, its toolbar menu carries Include items with no children. Turn it on and those items join the board. It is stored on the board, so everyone who opens it sees the same population, and it stays on when you move between levels. Like the level itself, it is switched only by someone who can change the board.

Two things it deliberately does not do:

• It does not include a parent whose items merely fail your criteria. That item has been broken down, and your query has already said its work is not what this board is about. Only items with no children at all join.
• It is not offered on the board's own level, or below it. There is no ancestry to complete there, so the option would be a switch with no meaning.

It costs nothing while it is off, because the board asks nothing extra of Azure DevOps until you turn it on.

What the board tells you

• "None of the items the query returned has a parent on the Features level." (or whichever level you picked) means the query is fine and the level is empty: none of its items is parented on that level. A level above then adds "To show Features that nobody has broken down yet, open More actions and turn on Include items with no children." Turning it on is how you see the undecomposed items, and how you can tell the query was never the problem. With the option already on, the board says it found no Features without children either.
• "None of the items the query returned has anything under it on the Backlog items level." (on a board of Features, for example) is the same answer for a level below: nothing on that level sits under the items the query returned.
• "The board found nothing on the Features level for the items the query returned." appears instead when some of those items could not be placed, which the notice "This level is missing N items" explains. The board does not claim they have no parent there, because that is exactly what it could not read.
• "Everything the board found on the Features level is outside the “Claims” team's area or iteration." appears on a board filed under a team. The board did find items on that level, and the team's area paths or backlog iteration left every one of them out, as they do with any card on such a board. One level up this is common: a delivery team's stories often sit under Features kept in a program area or at the project's root iteration. The board does not suggest Include items with no children here, because the team's scope leaves out what that option finds as well. To see those items, widen the team's area paths or backlog iteration, or move the board to the project list with Move to… (see Build a board that matches a team's own board).
• "The query returned no items." on another level means what it says: the query itself returned nothing, so there was nothing to find relatives of.
• "This level is missing N items because the board could not determine where they belong in the hierarchy" means an item on the way up could not be read, usually because it lives in a project you have no access to, or it was deleted after the query ran. Those items' parents are unknown rather than absent, and the board says so instead of quietly showing one card fewer.
• "The selected backlog level could not be loaded". Without the level ladder there is no "above" or "below" to work out, so the board shows what its query returns. Refresh to try again.
• "There are more items on this level than the board can check in one load" appears only when Include items with no children is on. Finding those means asking which items of the level have any children at all, and that search has limits: it looks at up to 5,000 items of the level in the population's projects, and it asks about their children in batches, reading at most 6,000 child links per batch. A level with a lot of items, or one whose items have many children each, can exceed either. The cards on the board are all real and all correct. What the notice says is that the childless part of the list is a lower bound, so an item missing from it has not necessarily been broken down. Nothing about this is transient, so refreshing will not change it. Narrowing your query will not change it either, unless the narrower query leaves out a whole project: the search reads every item of the level in those projects, whatever else your query filters on. A level with more items in those projects than Azure DevOps returns for one query (20,000) gets the same notice, and the board keeps the cards it found through the items' parents. The childless part of the list may then be empty.

Related

• Create a named board: the level you pick is stored on the board, so it is what everyone opening it sees.
• Build a board under an epic: the other way to get a board about one part of the hierarchy, where you pick a root, and the board is everything beneath it.
• Why items sit in Unmapped: what happens to an item on a level this board does not board.