The Infinite Backlog Problem
Every product backlog grows faster than it shrinks. Ideas come in from users, stakeholders, engineers, support tickets, competitor analysis, and shower thoughts. Each one feels important enough to write down. None of them ever get deleted.
The result: a backlog of 400 items, 350 of which will never be worked on. The backlog stops being a prioritized queue of upcoming work and becomes a graveyard of good intentions. When everything is in the backlog, nothing in the backlog is useful.
A Backlog Is Not a Wish List
The distinction matters. A wish list captures every idea anyone has ever had. A backlog is the prioritized, refined queue of work that the team is actually planning to do in the foreseeable future.
The practical rule: if an item has been in your backlog for more than 3 months and has never moved toward the top, it’s not a backlog item — it’s an archive entry. Either promote it or delete it. A backlog you can’t scroll through in under a minute is too long.
The Two-Tier Approach
Split your backlog into two tiers:
Active backlog — the next 2–4 sprints of work. These items are refined, sized, and ready to be pulled into a sprint. The active backlog should be 20–40 items for a typical team. Every item has clear acceptance criteria and a rough size estimate.
Icebox — everything else. Ideas that might be valuable someday but aren’t being actively planned. The icebox is not prioritized. It’s a flat list. Items in the icebox don’t get refined until they’re promoted to the active backlog.
This separation reduces the cognitive load of backlog management. You only need to keep 20–40 items in order, not 400.
Grooming Cadence
Backlog grooming (or refinement) should happen weekly, not before each sprint. A 30-minute weekly session keeps the active backlog healthy without requiring a marathon session before planning.
In each grooming session:
- Review the top 10 items. Are priorities still correct? Has anything changed that affects ordering?
- Refine 3–5 items. Add acceptance criteria, clarify scope, identify dependencies. Move refined items to “ready” state.
- Prune the bottom. Delete or archive items that have been below the fold for more than 2 months. If they were important, they’d have moved up.
Prioritization Frameworks
Every team needs a consistent prioritization method. The specific framework matters less than having one at all.
Impact vs. Effort — the simplest useful framework. Plot items on a 2×2 matrix. High impact / low effort goes first. Low impact / high effort gets questioned or dropped. The challenge: “impact” is subjective and teams often over-estimate impact on pet projects.
RICE scoring — Reach × Impact × Confidence ÷ Effort. More rigorous than impact/effort because it forces you to estimate reach (how many users this affects) and confidence (how sure you are about your estimates). Good for product teams with usage data.
Customer-driven — prioritize based on which items affect the most customers or the highest-value customers. Works well for B2B SaaS where specific accounts drive revenue decisions.
Opportunity cost — instead of asking “how valuable is this?”, ask “what do we lose by not doing this?” Features that prevent churn, avoid compliance violations, or unblock revenue have measurable opportunity cost. Features that are “nice to have” have low opportunity cost.
Writing Good Backlog Items
A backlog item should be understandable to someone who wasn’t in the room when it was created. The minimum viable backlog item includes:
- Title — specific enough to distinguish from similar items. “Fix login bug” is bad. “Fix: password reset email not sent when user has 2FA enabled” is good.
- Problem statement — what user problem does this solve? Not what the solution is — what the problem is. This allows the implementing engineer to find the best solution, which might be different from what the author imagined.
- Acceptance criteria — how will we know this is done? Specific, testable conditions. “User can reset password with 2FA enabled and receives the reset email within 60 seconds.”
- Size estimate — rough relative size. S/M/L or story points. Doesn’t need to be precise — it needs to be in the right order of magnitude.
Backlog Hygiene in FlowEra
FlowEra’s List view is designed for backlog management. Sort by custom priority fields, filter by status to see only “ready” items, and use saved filters to switch between your active backlog view and the full icebox.
Custom fields like “Priority Score” or “Customer Impact” can be added to any flow, making it possible to sort the backlog by a calculated metric rather than subjective ordering. The filter system supports multi-field sorting: sort by priority descending, then by creation date ascending, to see the highest-priority oldest items first.
Drag-and-drop reordering in the List view lets you manually adjust priority order during grooming sessions. The sort key persists, so the backlog order you set in grooming is the order the team sees during sprint planning.