# 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](https://anykanban.com/docs/share-and-navigate/who-sees-which-boards/#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](https://anykanban.com/docs/get-a-board/board-matching-a-team/)).
- *"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](https://anykanban.com/docs/get-a-board/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](https://anykanban.com/docs/get-a-board/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](https://anykanban.com/docs/concepts/why-items-sit-in-unmapped/):
  what happens to an item on a level this board does not board.