Find and analyze

Getting from four hundred cards to the one you need, and reading the board as evidence.

A board is a view of a query, and the query is almost always larger than the question you are asking right now. These pages cover the ways of narrowing it, and the two views that answer questions the columns on their own cannot: the arrows between cards, and the board as it stood on a past date.

Almost nothing in this group changes a work item. The filter, the arrows and the snapshot are read-only, and a baseline is stored with the board rather than written to any item. The List view is the only page here where a drag can write, and it writes the same order field the board does. Reordering there is off on a board whose type has no order field, while the query sorts by another field, and on a board of backlog items unless Reorder from this board (writes the backlog's own order) is turned on for it. A filter leaves it on: the row lands directly above the visible row below the slot, after any hidden rows between. Each row of the List also offers the card's own menu, so an item can be edited, moved or deleted from there as it can from its card.

Pages

• Find one item on a board of four hundred: the filter bar, a keyword box that matches ID, title, state and tags, plus the State, Assigned to and Tags facets.
• See which work is waiting on other work: Predecessor and Successor links drawn as arrows, red when the dependent item has run ahead of the work it depends on.
• Show the board as it was at the start of the month: the read-only As of snapshot, rebuilt from work item history rather than from a cache.
• See what changed since the plan was set: Set baseline records what every lane held, and the board then marks cards added or moved from another lane and lists what left, for everyone who opens the board. A lane that stands for an iteration in progress compares with the plan at the iteration's start with no click.
• See work that sits out of request order: a board of backlog items pointed at a request board marks the items that sit below where their request says they belong, and each reader may sort the board and the List by the requests' order. Neither writes anything. Take priorities is what reorders the backlog from them, after a preview.
• See everything the query returned, in one list: the List view, including the removed-state items the board deliberately hides, with the columns the board chooses and the card's menu on every row.
• Work with a column that has hundreds of cards: paging at 200 with Show more, and the 5,000-item data cap above it.
• Read the board by age at the daily meeting: the aging colors on the cards. By default each card is compared with what this board has actually finished, and, where a column has enough history of its own, with that step rather than with the whole process. A day limit your team sets in the board's settings takes precedence, and a board without enough finished history marks the card that has sat longest in each column instead.
• Read the Aging WIP chart: the third tab, every card in flight plotted by age against the board's own columns, with the p50/p70/p85 lines, the tails, the rings and the merged points explained one by one.
• What the chart is telling you, and what to do about it: seven shapes you will actually see, each photographed from a seeded board rather than drawn, and the move each one asks for.

What none of this does

Filtering never re-runs the query. It narrows what the tab has already loaded, so it can neither reveal an item the query did not return nor reach past the data cap. When something you expect is missing from the board, the query is where to look, not the filter bar.