refinement

Refinement

Turn the top of the backlog into Ready work. The bar: an Engineer could pick the item up and implement it without coming back with a question. Refinement works top-down in priority order — a beautifully groomed item at position 40 is wasted effort.

The Ready bar

An item is Ready when it has:

• a problem statement an outsider could understand (what + why, not just a title),
• acceptance criteria — observable outcomes, checkable one by one,
• a size the team believes (split anything that smells like an epic — see below),
• no open blocker, and its dependencies expressed as issue relations, not prose,
• an epic assignment if it serves one (via the board skill), and triage labels per docs/agents/triage-labels.md.

Process

1. Pull the backlog top via the board skill; take items in priority order.
2. For each item, test it against the Ready bar and fix what fails — draft the missing problem statement or criteria from the issue thread and the codebase, then confirm with the user rather than inventing intent. A question only the reporter can answer: ask it on the issue, label needs-info, move on.
3. Split items too big to size: slice by outcome (each slice independently shippable), never by layer ("frontend part" / "backend part" ships nothing). Each slice becomes its own issue under the same epic; the original becomes the epic or gets closed with pointers.
4. Set Status = Ready on the board as items clear the bar.

Stop when the Ready column holds roughly an iteration's worth of work (or the preset's buffer under Kanban) — refinement past that horizon goes stale before it's picked up.

Done when: every touched item either meets the full Ready bar, carries needs-info with a concrete question, or was split/closed — and the Ready buffer is restated in one line ("Ready now holds ~9 days of work").