Product backlog

The backlog is the holding area between vision (the durable product identity) and execution (sprints and the stories they contain). It lets us:

• Capture an idea the moment it arrives without committing to do it.
• Compare candidate work side-by-side when a sprint opens.
• Keep a record of what we could build, separate from what we will build.

Captures are non-stateful — no TODO, no Status table. Their only states are pending (the file sits in a bucket) and promoted (the file has been converted into a story under a sprint). On promotion the :ID: is preserved, so any document that linked to the capture still resolves once it becomes a story. The capture entry in document types describes the full frontmatter contract.

The buckets are not priority queues — they are horizons. Same idea, different reading audience:

Next

candidate work for the next version. Read during sprint planning and version-cut discussions. Concrete enough that someone can imagine the story / tasks; the scope is known well enough to argue about whether rather than how.

Deferred

the long-term wishlist. Read during retros, vision exercises, and "what should v2.0 look like" conversations. May be vague, speculative, or contingent on technology / people / time we don't yet have.

Discarded

ideas explicitly decided against. Not deferred — ruled out. Kept in version control (not deleted) so the rationale is preserved and the same idea is not re-proposed without context.

When you create a capture, place it in next if you can answer "yes" to all three:

1. Aligned — it fits the product identity; it isn't a left-field idea we'd never actually ship.
2. Scoped — the idea is concrete enough that you can see what the story would look like. Not necessarily small, but specific.
3. Eligible soon — there's a plausible path to pulling it into one of the next few sprints. Dependencies are either met or in flight.

Place it in deferred if any one of:

• The dependency story is long (months out, or "after v1.0").
• The idea is exploratory — "what if we…?" rather than "we need to…".
• It is a version-shaping idea (it would justify a new version rather than fit inside the current one).
• It is interesting but not yet aligned to identity — keeping it lets us reconsider during the next identity review.

If you genuinely can't decide, default to deferred. The cost of demoting a next idea later is higher than the cost of promoting a deferred one when its time comes — promotion is just git mv plus tag fixes; demotion is a sprint-planning conversation that didn't need to happen.

Move to discarded (via compass capture file <slug> discarded) when the team has made a conscious decision not to pursue the idea and wants a record of that decision. A discarded capture should include a brief note explaining the rationale.

inbox/ is the entry point for all new captures. Use compass capture --note "..." to file a quick note; it lands in inbox untriaged. At triage, move it to next, deferred, or discarded via compass capture file <slug> <bucket>, or promote it directly via compass capture promote <slug> --to story|task — the promoted doc keeps the capture’s UUID.

The old monolithic per-sprint capture.org is superseded; inbox is the single landing zone for all unprocessed ideas.

1. Created via compass capture --note "..." (lands in inbox/) or directly via compass add capture --parent-dir doc/agile/product_backlog/<bucket>. The capture lives in its bucket directory with any supporting files.
2. Refined during backlog refinement: the body is tightened, tags are updated, the bucket may be moved (git mv between next/ and deferred/ is cheap).
3. Promoted when a sprint pulls it in: the file is moved into the relevant sprint story folder as story.org; #+type: flips from capture to story; the :ID: is preserved so existing references continue to resolve; the standard story shape (blurb, Goal, Status table, Acceptance, Tasks, …) is filled in. The indexes (next, deferred) drop the entry on next regeneration.
4. Abandoned if reconsidered and dropped. The file is deleted.

The bucket indexes are auto-generated by projects/ores.codegen/scripts/regenerate_backlog_indexes.py — do not edit their tables by hand; add a capture and re-run the script.

• Inbox — every untriaged capture.
• Next Bucket — every next capture, one row each.
• Deferred Bucket — every deferred capture, one row each.
• Discarded Bucket — every discarded capture, one row each.

External reading:

• On Product Backlog — earlier essay on how stories flow from capture to implementation. Conceptually correct, but not up-to-date with the cybernetic v2 approach (it predates the capture / story split and the next/deferred buckets).