Backlog Management

One backlog, one source of truth: Jira. Everything the team works on lives there — features, bugs, tech debt, infra, spikes, docs, incident follow-ups. If it's worth an engineer-hour, it's worth a ticket.

The full workflow, field rules, GitLab linking and Jira setup are in conventional/jira.md. This section is the summary.

Principles

• One tool. Jira holds the description, discussion, approval and status. No separate ticket page, no GitLab issue.
• Bugs, debt, and features compete in one queue. A High bug and a High story go through the same prioritization. That's the point.
• WIP limit: 1–2 subtasks In Progress per engineer. More than that is context-switching dressed up as productivity.
• Single assignee per subtask. Shared ownership becomes no ownership.

Hierarchy

Level	Jira type	Created by	What it is
Epic	Epic	BA or PM	A multi-week goal: "Migrate billing to v2", "Cut p95 latency below 300ms"
Work item	Story, Bug, Task	Story: BA. Bug, Task: anyone	One outcome that can be verified on staging and shipped by a release
Engineering unit	Subtask	The BE or FE engineer doing it	One engineer's piece, usually one MR, at most 3 days

BAs own Epics and Stories; engineers own their subtasks. Branches and MRs carry the subtask key.

Lifecycle

A work item (Story, Bug, Task) moves through fixed states:

Backlog → Refinement → Ready → In Progress → In Verification → Ready for Release → Done

Any state can exit to Closed (duplicate, won't do, stale, or out of scope), always with a one-line reason.

State	Meaning
Backlog	Filed. Not yet looked at in detail.
Refinement	An engineer researches it and asks questions; the BA writes the detailed spec. Timebox: two days.
Ready	Meets the Definition of Ready. Work can start.
In Progress	At least one subtask is being worked on. Set by automation.
In Verification	Every subtask is merged, so the work is on staging. Set by automation.
Ready for Release	The owner verified it and the BA accepted it, on a named staging build. Fix Version set.
Done	Live in production: its Fix Version was released. Set by automation.
Closed	Killed without being shipped. Always leave a one-line reason.

Subtasks have their own short flow: To Do → In Progress → In Review (MR open) → Done (merged to main, on staging).

Engineers pull from Ready, not from Backlog or Refinement. Starting before the spec is clear is how scope explodes mid-iteration.

Refinement

Engineers don't wait for a finished spec; they help write it. At grooming an engineer (normally the one who will build it) is assigned and the work item moves to Refinement. The engineer spends an hour or two on research — the code and data it touches, edge cases, dependencies, risks — and posts specific questions on the ticket for the BA. The BA answers by extending the description into the detailed spec: the endpoints we will support with a note each (paging, filters, what comes back), rules and failure cases, a short flow when the feature spans several steps, Given/When/Then acceptance criteria and test scenarios. A 15-minute review (engineer, BA, lead) creates the subtasks, tags each scenario auto or manual, and moves it to Ready.

Definition of Ready

A work item is Ready when all of the following are true:

• The description follows the detailed spec template: goal, endpoints with a note each (if any), rules, a flow when the feature spans several steps; every failure case written down
• Acceptance criteria written as Given / When / Then
• Test scenarios cover every acceptance criterion, each tagged auto or manual
• Open questions is empty — the engineer's research questions are answered in the description
• Dependencies are named and confirmed available
• Linked to its Epic (Stories), component set, work item owner named
• Subtasks created and estimated by the engineers who will do them; the lead confirmed the estimates

Categorization

• Issue type: Epic, Story, Bug, Task, Subtask. Nothing else.
• Priority: Highest (drop everything), High (this iteration), Medium (next iteration), Low (someday).
• Component: matches our domain owners (auth, billing, ingestion, etc.).
• Labels, only when there's a real reason to filter: tech-debt, infra, spike, docs, incident, incident-followup, parked.

Investment budget

Roughly 20% of each iteration's capacity is reserved for tech debt, infra, tooling, and unplanned work. Not a soft target — a budget. If features eat it, debt compounds and you'll feel it in two quarters. (See Tech Debt & Investment for how we identify investment work.)

Hygiene rules

• Backlog > 2 weeks old without refinement → refined or closed.
• Low priority > 6 months old → closed. Re-file if it actually matters.
• No ghost owners — every In Progress subtask has exactly one assignee.
• Incidents are tickets. The incident itself is a Jira Task labelled incident holding the postmortem; its action items are Jira Tasks labelled incident-followup.
• Done means released — live in production. Not "MR approved", not "verified on staging".

Cadences for the backlog

Already covered in Working Cadence, summarized here:

• Weekly grooming (30 min) — refine Backlog into Ready, prune stale tickets. Lead + BA + one rotating engineer.
• Iteration planning (45–60 min) — pull from Ready. Whole team.
• Quarterly tech health review (90 min) — see Tech Debt & Investment.