<!-- last-reviewed: 2026-06-01 · owner: Product (Product Manager) -->

SOP-068 — Backlog management (intake → story → RICE → groom → sprint story set)

SOP · owner: Product (Product Manager). Layer: SOP/Runbook (docs/canon.md). The requirement interface between upstream strategy (Innovation / Design Research / CPTO) and downstream Engineering. Links to canon; does not restate it.

Interface Contract

• Inputs: accepted concept brief ← from <Innovation Director / CPTO> · trigger: gate package ready
• Inputs: research findings ← from <Design Research Director> · trigger: research findings issued
• Inputs: implementation risk against a story ← from <Engineering> · trigger: implementation risk raised
• Outputs: sprint story set → to Engineering Director · trigger: story set accepted
• Outputs: prioritised ready backlog → to Project Manager · trigger: backlog ready
• Outputs: approved backlog snapshot / RICE scorecard → to Archivist · trigger: artifact approved
• Outputs: docs/product/ canon Index row change → to Documentarian · trigger: document changed
• Handoff trigger (in): an Innovation concept brief is accepted at the Ideate→Plan gate, OR Design Research issues findings, OR Engineering raises a risk against an existing story
• Handoff trigger (out): a sprint’s story set is accepted (acceptance-criteria-complete) and handed to Engineering; the prioritised backlog is handed to the Project Manager to sequence
• Definition of Done before handoff:
  • [ ] every story in the set is well-formed (As a <specific user>, I want <what>, so that <why>)
  • [ ] every story carries complete, testable acceptance criteria (SOP-069) — no story without criteria
  • [ ] every story names its source (provenance); none written from air
  • [ ] every story is independently deliverable (single increment; oversized stories split)
  • [ ] RICE scored; priority order recorded with input reasoning
  • [ ] major priority shifts (delaying committed work) carry written CPTO sign-off
  • [ ] no technical approach prescribed in any acceptance criterion (Engineering owns how)
  • [ ] learnings captured to docs/knowledge/ if any (reported for indexing, SOP-024)

Trigger status: research findings issued, story set accepted, and backlog ready are now registered (docs/handoff-triggers.md, Wave-2 block, Operations-approved 2026-06-01). The Ideate→Plan concept handoff uses the canonical gate package ready (the variant concept brief accepted was folded into it — reuse-beats-add). requirements issued (Legal→Engineering) is a distinct event, so story set accepted is kept separate. The implementation risk input declares a placeholder producer (<Engineering>) — a fan-in sink (§3.1 R1); the Innovation / Design-Research producer edges are pending (those Directors are not Interface-Contract identities here — §3.1.1 R3).

Purpose

Maintain a single, prioritised product backlog so each sprint begins with a defined, accepted set of stories Engineering can build from — never from raw concept briefs. This is the gate that keeps requirements and implementation in different hands.

When to use

• An Innovation concept brief is accepted at the Ideate→Plan gate (concept brief accepted).
• Design Research issues findings that change or refine requirements (research findings issued).
• Engineering raises a risk/dependency against a story (implementation risk raised).
• Continuously, for grooming — backlog management is not a one-time event.
• At sprint start, to assemble and hand off the sprint story set.

Flow

flowchart LR
  A["Receive upstream input<br/>(read in full)"] --> B{"Gap / ambiguity<br/>/ silent on user?"}
  B -->|yes| R["Raise to originator<br/>(do NOT invent scope)"]
  B -->|no| C["Write user stories<br/>(value increments)"]
  C --> D["Write acceptance criteria<br/>(SOP-069)"]
  D --> E["RICE score<br/>+ record reasoning"]
  E --> F{"Major priority shift<br/>delaying committed work?"}
  F -->|yes| G["CPTO sign-off<br/>(written)"]
  F -->|no| H["Groom backlog<br/>(split / retire / update)"]
  G --> H
  H --> I["Assemble sprint story set<br/>→ Engineering 'story set accepted'"]
  I --> J["Hand backlog → PMO 'backlog ready'<br/>+ archive 'artifact approved'"]
  classDef s fill:#1d4ed8,color:#fff,stroke:#1e3a8a
  classDef d fill:#0f766e,color:#fff,stroke:#134e4a
  class A,R,C,D,E,H,G,I,J s
  class B,F d

Text fallback: receive and read the upstream input in full → check for gaps; if ambiguous, underspecified, or silent on the user, raise it to the originator and stop (no scope invention) → write user stories (one value increment each) → write acceptance criteria (SOP-069) → RICE score and record the input reasoning → if a major priority shift delays committed work, get written CPTO sign-off → groom (split oversized stories, retire stale ones, update on new evidence) → assemble the sprint story set and hand to Engineering (story set accepted) → hand the prioritised backlog to the Project Manager (backlog ready) and approved snapshots/scorecards to the Archivist (artifact approved).

Steps

1. Receive & read. Open the upstream source in full. Do not paraphrase a concept brief — surface its exact hypothesis, riskiest assumption, and recommended scope as the basis for stories.
2. Identify gaps before writing. If the brief/finding is ambiguous, underspecified, or silent on who the user is, raise it back to the originating agent (Innovation / Design Research) and pause story-writing for the affected scope. Never invent scope to fill a gap.
3. Write user stories. One or more per feature, form As a <specific user type>, I want <what>, so that <benefit>. Each independently deliverable, scoped to a single value increment. Name a specific user — “as a user” is a defect.
4. Write acceptance criteria per SOP-069 (Given / When / Then + non-goals). No story leaves this step without criteria.
5. RICE score. For each candidate, record Reach, Impact, Confidence, Effort and the reasoning behind each input. Compute RICE = (R × I × C) / E. The resulting order is the backlog priority. Use the scorecard template (§ below).
6. Check for a major priority shift. If the new order delays previously committed work, prepare a brief rationale and obtain written CPTO sign-off before committing the new order or communicating it downstream.
7. Groom. Split stories too large for one sprint; retire items no longer relevant; update stories when new research evidence arrives. Continuous, not one-time.
8. Assemble the sprint story set. At sprint start, produce the ordered list of accepted, acceptance-criteria-complete stories. Hand to the Engineering Director (story set accepted); notify the Project Manager the input is ready (backlog ready). Do not negotiate scope with Engineering at sprint start — priority is set before sprint planning begins.
9. Update the roadmap (SOP-070) after major prioritisation decisions or gate approvals.
10. Capture & archive. File any learning to docs/knowledge/ (report for indexing, SOP-024); hand approved snapshots and RICE scorecards to the Archivist (artifact approved).

RICE scorecard format (record in docs/product/backlog.md or a sibling scorecard)

Roles / approvers

• Product Manager — authors stories, acceptance criteria, RICE scores; owns the backlog; assembles the sprint story set; the only agent who writes and accepts stories.
• CPTO — signs off major priority shifts; reviews at the Ideate→Plan / Plan→Build gates. (Direct reporting line; not a registry handoff edge.)
• Innovation Director / Design Research Director — originate the upstream inputs; resolve gaps raised back to them.
• Engineering Director — downstream consumer of the sprint story set; raises implementation risks back.
• Project Manager (PMO) — sequences the ready backlog into milestones (delivery sequencing is theirs, not ours).

Guardrails

• No story without acceptance criteria (charter Operating rule 1).
• No scope invention — raise gaps, do not assume (rule 2).
• No technical approach in acceptance criteria — Engineering owns how (boundary 1).
• Evidence over preference — RICE + upstream evidence drive priority; not enthusiasm (rule 4).
• CPTO sign-off on major priority shifts before downstream comms (rule 5).
• Delivery sequencing belongs to the Project Manager — we hand a ready backlog; we do not set milestones or timelines.
• Personal information is PA-only — never accessed here.
• Links to policy: hr/employee-handbook.md, hr/policies/*; rules CLAUDE.md.

See also: docs/units/product/charter.md · SOP-069 (acceptance criteria) · SOP-070 (roadmap) · docs/methodology.md (Ideate→Plan gate) · interface-contract-spec.md · docs/handoff-triggers.md.