Backlog Prioritization Checklist

Filter to items in Backlog and Ready states; exclude Done, In Progress, and Icebox. Export to a working sheet or use a saved JQL/Linear view so the same set is visible to engineering and design before the grooming session.

Stale tickets distort velocity math and hide active work. If nobody has commented or re-estimated in 90+ days, close as won't-do and move the rationale to a Confluence/Notion archive page so it can be revived if priorities shift.

Items that don't map to a current-quarter OKR or a named customer commitment are candidates for the icebox. Don't accept "strategic" without a named outcome — it's how zombie work gets prioritized.

Use a t-shirt scale (S/M/L/XL) tied to dollar bands appropriate to your ARR — e.g., S = under $10k ARR, XL = over $250k ARR. Pull numbers from Salesforce/HubSpot opp data or support tickets blocked by the gap, not gut feel.

RICE = (Reach × Impact × Confidence) / Effort. WSJF = Cost of Delay / Job Size. Pick one and stick with it across the quarter — switching frameworks mid-stream makes scores incomparable. Document confidence levels honestly; a 50% confidence score is more useful than a fake 90%.

Story-point any item that doesn't already have an estimate. Items larger than 8 points (or 13 depending on your scale) should be split before they enter a sprint — oversized stories slip and hide their slip until late in the sprint.

Flag items that need API changes from the platform team, schema migrations, IaC changes from DevOps, or design assets not yet started. Dependency surprises late in the sprint are the most common cause of carry-over.

Schema changes on tables over a few million rows need batched backfills and concurrent index strategies. Mark these for an explicit migration plan review before they enter sprint commit — surprise locking migrations cause production incidents.

For each migration: ADD COLUMN with no default, batched backfill with sleep, follow-up to set the default in a separate deploy. Reversibility matters — confirm the previous container image is still in the registry and that the migration is forward-only-safe under canary rollout.

Pull the tech-debt label from Jira/Linear plus the SRE backlog. Common candidates: stale feature flags, deprecated library upgrades, flaky tests in CI, runbook gaps for on-call. Reserve roughly 20% of sprint capacity for debt — under-investing here compounds.

Review CVSS scores; Critical and High get sprint slots within SLA (commonly 7 days for Critical, 30 for High under SOC 2 vuln-mgmt controls). Don't let major-version upgrades pile up — that's how you discover at Log4Shell time that you can't upgrade.

Critical CVEs override RICE/WSJF ordering — they get committed to the next sprint regardless of effort score. Document the swap and what business work is being deferred so the trade-off is visible to stakeholders.

Likelihood × impact, 1–5 each. Items touching auth, billing, or data-export pathways carry higher impact regardless of perceived simplicity. High-risk items need an explicit rollout plan — feature flag, canary, or dark launch.

Pull top items from the support ticket tracker (Zendesk/Intercom labels), CS QBR notes, and sales' deal-blocker list. Each request needs a named customer or a deal value attached — "a customer asked for this" without specifics doesn't survive the prioritization session.

Scan competitor changelogs, G2 review mentions, and analyst notes (Gartner/Forrester if relevant). Identify gaps where churn risk or stalled deals correlate with the missing capability — not feature parity for its own sake.

SOC 2 audit windows, GDPR data-subject-request SLAs, customer DPA commitments, accessibility (WCAG 2.1 AA) deadlines for public-sector contracts. These are non-negotiable slots in the sprint regardless of score.

Reorder in Jira/Linear so the rank in the tool matches the priority decision — don't leave it as a separate spreadsheet that drifts. Engineers pull from the top; ambiguity at the top of the queue costs sprint hours.

Pull stories from the top of the ranked list until you hit the available story points from the prep step. Leave a small buffer (10–15%) for incoming bugs and on-call interrupts; teams that commit to 100% of capacity routinely carry over.