The two-backlog model

The single biggest change to how SDLC Studio is used: there are two backlogs, and a request only becomes work by crossing between them.

The two backlogs

• Discovery backlog - what someone wants. Change requests (CRs) and RFCs. An idea, a bug report, a design question. Cheap to file, unsized, not yet committed.
• Delivery backlog - what the team will build. Epics, stories and bugs, each carrying acceptance criteria and a size. This is the sprint’s raw material.

A request in the discovery backlog is not work. It becomes delivery work only when refine decomposes it into sized units. That crossing is the whole point.

Discovery backlog                 Delivery backlog
─────────────────                 ────────────────
CR: "export my data"   ─refine─▶  EP: Data export
RFC: "should we cache?"           ├─ US: request + queue   (3 pts, ACs)
                                  └─ US: deliver the file  (2 pts, ACs)

Why the split exists

Merge the two and every idea looks like committed work. A one-line “wouldn’t it be nice” sits in the same list as a sized, accepted story, and planning quietly treats them alike - so the plan fills with things nobody scoped, estimates collapse to a floor, and “the backlog” stops meaning anything.

Keeping them separate makes one rule enforceable: you cannot plan a sprint over an un-refined request. The breakdown gate refuses it. A change that arrives without a sized unit behind it is caught, not shipped.

refine - the crossing

refine reads a CR or RFC and produces the delivery units that satisfy it: an epic and its stories (or bugs), each with Given/When/Then acceptance criteria and a point size relative to work you have already delivered.

/sdlc-studio refine --id CR0421

Grooming is real work, and it sits on top of the points. A freshly refined story is a scaffold: its acceptance criteria are placeholders until you author them against the specific slice. Refine first, then groom the criteria, then plan.

Note

A request reaches its terminal status (a CR is Complete, an RFC has its own terminal) only when the delivery units it decomposed into are all Done. You do not close a CR by hand - it is derived from its children. Delivery drives discovery, never the other way round.

Bugs and issues

• A bug is delivery work: a defect with a severity and a size, filed straight into the delivery backlog. It is fixed through a story-like path and its Done gate.
• An issue is a discovery-tier report you have not yet triaged. triage turns an issue into bugs (or closes it). Like a CR, an issue is not work until it is decomposed.

Sizing is compulsory

Every delivery unit carries a size - modified Fibonacci story points on a story or bug, a T-shirt size on a CR/RFC/epic. Sizing is what makes the estimate a number rather than a guess, and it is what lets the planner see that two units touch the same file and cannot run in parallel. The tooling refuses an un-sized unit into a plan; a bug’s severity is its urgency, a different axis from its size.

What this means day to day

1. Someone has an idea → file a CR (or an RFC for a design question). Cheap, unsized.
2. You accept it → refine it into an epic + sized stories, then groom their acceptance criteria.
3. Now it is delivery work → sprint plan a batch of it, build, verify, review, close.
4. The CR goes Complete automatically when its stories are Done.

See also

• RFC vs CR - which kind of request to file.
• Sprint planning - how a delivery batch becomes a sprint.
• Executable acceptance criteria - what grooming produces.