Why AnyKanban never writes to someone else's backlog
Short answer: a card links to existing backlog work with the Related link type and nothing else. It never links an existing item as its parent or its child. The items it links with Related have no checkboxes anywhere either. And on a board of backlog items, the backlog's own order is read and never written, unless someone deliberately turns that on for the board, which is off by default and covered below. Linking upward can therefore never displace, reparent or close somebody else's work.
Where the rule comes from
The cards on these boards hold work item types that sit outside the backlog: business requests, change requests, support requests, risks. If they sat inside the hierarchy, a native Azure Boards board would already show them and there would be no reason for this product to exist.
Parent/child links would also have to pick a direction, and the right direction depends on the relative level of the two items: a feature on a business-request card is above it, a backlog item is below it. Worse, Azure DevOps allows a work item one parent. "Link this card to that epic" would then either fail or silently replace a parent somebody else set. Related has neither problem: no direction, no single-parent constraint, nothing to overwrite.
The consequence is a feature rather than a compromise. One card can legitimately link one team's epic and another team's feature at the same time, which is exactly what a demo card like Be ready for the 2027 regulatory reporting regime does, linking two epics in two different projects.
No checkboxes, on purpose
Linked items share the card's chip row with the task and bug checklists but behave differently inside it: a linked item has no checkbox and cannot be dragged, and the only thing you can add there is another Related link, either to an existing work item or to a new one created in the Azure DevOps dialog. Planned work shows a progress count; every other linked item shows a state badge. You do not close another team's epic from a support card, and no arrangement of the UI should let you do it by accident.
The rollup only ever reads. It walks descendants to count them and writes nothing at any depth.
What the card does write
The distinction worth keeping straight is whose work it is:
- Its own children, meaning the Tasks and Bugs checklists. Ticking a box moves that child to its own type's completed-category state; dragging a task writes that task's own ordering field; Add task creates a task under the card, in the card's project, area path and iteration path.
- Its own backlog-level children, meaning the chip for the level below (a Feature's stories, an Epic's features) carries the same checkbox the native card draws there: ticking it closes the card's own child through that child's process states. The box is always offered and never pre-disabled, because the server is what checks the close, and a refusal reverts the tick with the server's own message. No drag, and no rank write: the order shown is the backlog owner's.
- A new child it creates. On a card that is itself a backlog item, the add affordance (named for what it creates: + Add Feature) makes a brand-new work item of the backlog level directly below the card's own, in the card's project, area path and iteration path, with its parent link set in the same creation. That is the native quick-add pattern: a newborn has no other parent to displace, so nothing anyone else set can be overwritten. The rule this page is named for is about linking existing items: that stays off the list entirely.
- Items linked with Tested By, meaning the Test cases section, with the same checkbox behavior, on from the start on a board of backlog items or of bugs and off on other boards.
- The card's own work item: state on a drag, rank on a reorder, the split
flag and lane fields a drop implies, and inline field edits. Rank carries one
deliberate exception: on a board of backlog items, whether stories, features or
epics, the ordering field is the product owner's prioritization, so the board
reads it and never writes it until you say otherwise. By default cards
follow the backlog's order (sorted for you when the query has no
ORDER BYof its own), an in-column drag is inert, and the card menu says why, with Reordering is off because the backlog owns this order where Move to top/bottom would be, with Why reordering is off and how to enable it beneath it. When the query sorts by anything other than the order field, ascending, the board is showing the query's order instead, and the menu names that source: The query controls order. AnyKanban never writes backlog order. Where Reorder from this board is on and nothing in its list of limits below stands in the way, a card of the board's own type says Reordering is off while the query sorts by … instead, because there the sort is all that stands in the way.
The card also adds links and items of its own. Add related links an existing work item to the card with Related, and Create new under it opens the native Azure DevOps dialog for a new item linked the same way. Add test links an existing test case with Tested By, or creates a new test case linked the same way. Delete in the card menu moves the card's own work item to the project's recycle bin, where an administrator can restore it. Apart from the Related link itself, which shows on both ends, nothing here changes a backlog item reached through a Related link, at any depth.
When you do want to reorder the backlog from here
The read-only default is a judgment about whose order it is rather than a technical limit, so it can be lifted, deliberately, per board.
Board settings → Reorder from this board. Ticking it opens a confirmation that says what it costs, because the consequence lands outside the board: the order you write is the order every other team reads, and nothing on their own backlog will say it came from here. Once it is on, the board carries a notice that cannot be dismissed, because one person makes the decision, and everyone who opens the board afterwards inherits it. On a shared board that person is someone who can change the board: whoever created it or a project administrator, and on a board in a team's group, that team's administrators too.
An administrator can also make this the starting point for new boards: the AnyKanban page in Organization settings has a Backlog boards may reorder the backlog option under Defaults for new boards. With it on, a new board starts with reordering on and does not ask for the confirmation again. Its notice still appears and still cannot be dismissed. The option is offered to people with the Edit instance-level information permission and shown read-only to everyone else, as a guard against accidental change.
Five limits are worth knowing before you turn it on:
- It only unlocks this board's own type, in this board's own project. A backlog item of some other type that the query also returned keeps its owner's rank, and so does an item from another project that happens to share a type name. On a board whose definition names the project its type belongs to, because that is not the project the board is opened from, the named project is the board's own: its cards can be reordered, and a card of the same type from the project the board is opened from keeps its owner's rank. An item added inline on such a board is created in the project the board is opened from, so it starts without a rank there.
- It does nothing when the query sorts by anything other than the rank
field, ascending. The board is then showing the query's order, so a drop
between two rows is not a position in the backlog and there is nothing
honest to write. A query with no
ORDER BY, or one that sorts by the order field ascending as its first key, shows the backlog's order, and there the setting works. While the setting is on, the query sorts by something else and nothing else in this list stands in the way, a line above the board names the field the query sorts by, and so does the card menu of each card of the board's own type. - It does nothing when the board's backlog level holds more than one type, for example stories and bugs on the same backlog. The checkbox is still there, but the setting unlocks a single type and the cards shown interleave two or more, so the board keeps the backlog's order read-only.
- It does nothing while the toolbar's Level shows a level other than the one the query returns. The cards are then the query's relatives, so a position between two of them is a position among items you cannot see.
- It is not available on an ad-hoc board opened straight from a query, which has no saved definition to carry the setting.
Nothing about this bypasses Azure DevOps. Every write still runs as you, under your own permissions, and a refused write is reported rather than swallowed.
When the backlog should follow the business's requests
A second option, separate from the first, lets a shared board of backlog items reorder the backlog from the order of its requests on a request board: Let Take priorities from … reorder the backlog, on the General tab below Request board. It is off by default, a new board never starts with it on, an imported board arrives with it off, and it asks for a confirmation before it is turned on. Turning on one of the two options never turns on the other.
It is also more careful than a drag, because it reaches further. It can move items on the levels above and below the board's own cards. With the choice its preview starts with, it moves only items with a request of their own. With The whole hierarchy chosen, it can move every item on the levels it reaches: an item with a request of its own is placed by that request, the others follow the item above them, and an item with no request and nothing above it to follow goes after the items that have one. Either way it moves only items in the area paths the board's cards use (or, on a board filed under a team, the team's own) unless the reader adds another area for one run with Also reorder these, and only after a preview that lists every item it would write. Items of other teams that it passes on the way keep their own order, and one that has a request is passed only in the direction request order says. With The whole hierarchy, a request an item takes from an item above it counts as well, and a move down never passes one of their items that has no request at all. It writes the order field and nothing else, and it never links an item to a request. See Put the backlog in the order of its requests.
What it means in practice
- Link freely and link more than once. Multiple links are legitimate, and adding one takes nothing away from anyone.
- Remember that a Related link in Azure DevOps is visible from both ends: the epic's own Related list will show your card. That is good for traceability and worth knowing before you link.
- To actually change a linked backlog item, click its title. The native work item form opens, with that item's own process, rules and required fields, which is where such a change belongs.
- The board also never changes your process. It reads the process configuration and adapts to it; it adds no fields, states, rules or backlog levels. The one exception is the field setup on the organization settings page, and it works only in an inherited process. There it can create a field, prepare an inherited copy of a work item type where the field needs one, and put the field on that type. It never adds a state, a rule or a level, and it acts only when your administrator has read the plan and presses Execute plan.