# Break work down on the card without a backlog

A support request like "Kestrel Logistics: claim 2026-04417 stuck after adjuster
upload" needs two or three concrete steps, not backlog items. Child tasks live on
the card itself, behind a small chip carrying the task icon and a done counter,
ticked to complete and dragged into order.

## Before you start

**Show tasks on cards** (board settings, **Annotations** under **Cards**) is on
from the start on a board of backlog items and on a board fed by a tree query;
on a board like this one, turn it on first. A chip
appears only on a card that already has at least one child of that kind. For
the first one, use **Add task** in the card's **…** menu, and the rest from the
card itself.

A card shows one chip per kind of work beneath it, and which kinds those are
comes from your own backlog: whatever sits on the next level down. On a board of
support requests that is your task level; on a board of features it would be
your stories. Bugs get their own chip wherever your project's *Working with
bugs* setting puts them.

## Steps

1. On the card, select the **task chip**, the task type's own icon with **1/2**
   beside it: one of the two child tasks is done. Hovering it spells that out,
   *1 of 2 Task completed*.
2. Tick "Re-run the document ingestion for claim 2026-04417". Its title is struck
   through and the counter becomes 2/2.
3. Select **+ Add task**, directly under the chip, type a title and press Enter.
   The box stays open and empty for the next one, so several tasks are several
   titles and Enters. Press Enter on an empty box, or Escape, to put it away;
   leaving the box also creates whatever is in it.
4. Reorder a task: press on a row and move about 4 px to start the drag, then
   drop it, or focus the row, press Space, move with the arrow keys and press
   Space again.
5. Click a task's title to open it in the native work item form. Closing the form
   re-reads that one task, so a change made there shows on the card at once.

## What you should see

The counter and the strike-through follow every tick immediately, and the write
goes to the server behind them. The new task has no order value yet, so it sorts
to the end of the list; it is created in the parent's own project, area path and
iteration path, with the first work item type of that project's task backlog
level. The order you drag into is written to the task's own ordering field, so
the sprint taskboard and any query see the same order.

![Tasks added straight to the card, with a done counter](https://anykanban.com/docs/_img/card-tasks-checklist.png)

## Notes

The checkbox never keys on a state name. Ticking writes the child type's first
**Completed**-category state and unticking writes its first **Proposed**-category
state, which is "Done" and "To Do" in the demo process, whatever your own process calls
them elsewhere. If the type has no state of that category, nothing is written and
a message says so instead.

Only task rows can be dragged into order. Test cases keep a fixed order (state
name, then ID) because Azure DevOps stores no order for Tested By links, and
bugs shown as a chip of their own keep the same order. Adding is not limited to
tasks: the test chip has its own **Add test** and **Link existing**, described
in [See which tests cover a change](https://anykanban.com/docs/follow-work-through-links/see-which-tests-cover-a-change/), and on a
feature or epic card the chip for the level below has its own **+ Add** box
named after that type.

## Related

- [See which tests cover a change](https://anykanban.com/docs/follow-work-through-links/see-which-tests-cover-a-change/)
- [Link a request to the backlog items that implement it](https://anykanban.com/docs/follow-work-through-links/link-a-request-to-backlog-items/)
- [A board for types that never reach a backlog](https://anykanban.com/docs/guide-types-outside-the-backlog/)