Synonyms: product backlog, sprint backlog, work queue, task list, prioritized to-do list
Do not index
Definition
A backlog is an ordered list of everything a team might build, including features, fixes, UX debt, research, and design tasks, ranked by what matters most. It's the single source of truth for what's coming next. For UX, the catch is making sure design and research work actually sits on it with the same visibility as engineering, or it gets quietly skipped.
Use cases
Leave UX off the backlog and it becomes invisible, which makes it the first thing cut.
Design work that doesn't exist: Research and design aren't on the list, so the team plans sprints around engineering tickets and treats UX as optional. It gets squeezed every time.
Building blind: The backlog is all features and no discovery items, so the team ships things nobody validated, fast.
Vague items, endless debate: "Improve onboarding" sits there with no shared definition, so every planning meeting re-argues what it even means.
How it's used in practice
Put UX on the backlog: Add design and research as their own items, tagged and ranked alongside development, so the whole team can see them.
Write items as outcomes: Use user stories ("As a user, I can...") with acceptance criteria, not vague task names.
Rank, don't hoard: A backlog is a ranking, not a dumping ground. Force a real order instead of a flat wishlist.
Refine regularly: Re-score, re-rank, and delete dead items so the list reflects reality, not history.
🪄
Pro-tip: A backlog is a graveyard if you let it be. The danger is a thousands of stale tickets hiding the 20 that matter. Delete aggressively. If something's sat untouched for a year, it's noise. And if UX work isn't on the backlog with a rank, it doesn't exist to the team.
Challenges & limitations
Bloat: Backlogs balloon into thousands of items nobody reads, burying the work that counts.
Ranking is political: Prioritization can default to whoever argues loudest unless the team commits to a shared method.
