backlog-management
Backlog Management
Keep the backlog sharp, honest, and useful — not a guilt-inducing pile of good intentions.
How to use
/backlog-managementApply backlog management constraints to this conversation./backlog-management <context>Improve backlog practices for the described situation.
Constraints
Backlog Hygiene
- MUST review and prune the backlog at least monthly. Stale items erode trust.
- Any item untouched for 90 days SHOULD be either re-prioritized or killed
- MUST limit backlog size. If it takes more than 15 minutes to scan, it's too long.
- SHOULD separate the "ready to build" backlog from the "idea parking lot"
- NEVER treat the backlog as a promise. It's a prioritized list of options.
Item Quality
- Every backlog item MUST have: clear problem statement, acceptance criteria, and rough effort estimate
- SHOULD tag items by: theme, user segment, business impact, and status
- MUST ensure top 10 items are detailed enough to start working on immediately
- Items below top 20 SHOULD be epics or themes, not detailed tickets
- NEVER let vague items ("improve the dashboard") stay in the backlog. Sharpen or kill.
Grooming Practices
- MUST run regular grooming sessions to refine upcoming items
- SHOULD involve engineering in grooming — they catch feasibility issues early
- MUST split items that are too large to fit in a sprint
- SHOULD estimate effort collaboratively, not have PM assign estimates unilaterally
- NEVER let grooming become a multi-hour ceremony. Timebox to 30-60 minutes.
Saying No
- MUST close items that won't get built in the foreseeable future
- SHOULD have a clear process for declining requests: acknowledge, explain, document
- MUST distinguish between "not now" and "never" — communicate which one clearly
- NEVER accumulate items out of guilt or fear of saying no
- SHOULD track patterns in rejected items — if the same request keeps coming back, investigate
Anti-Patterns
- The Infinite Backlog: 500+ items that nobody has read in months
- The Guilt Backlog: keeping items because someone important asked for them years ago
- The Ungroomed Sprint: pulling items into a sprint that haven't been refined or estimated
- The Living Jira Cemetery: items marked "in progress" that nobody is actually working on
- The Wishlist: a backlog full of ideas with no prioritization, estimation, or acceptance criteria
More from dragoon0x/product-skills
prd-writing
Write product requirement documents that engineers want to read and can actually build from. Covers structure, scope discipline, and the balance between clarity and over-specification. Use when writing PRDs, reviewing spec quality, or when engineering keeps asking clarifying questions.
1freemium-vs-paid-gate
Decide whether a product should offer a free tier, free trial, or go straight to paid. Structured decision framework based on economics, distribution model, and competitive landscape. Use when launching a new product or reconsidering your pricing model.
1error-recovery
When things break, guide people forward instead of leaving them stranded. Error message copy, retry patterns, graceful degradation, and recovery flows. Use when building error handling or failed state UIs.
1cta-patterns
Design calls-to-action that people actually click. Covers button copy, placement logic, urgency without manipulation, and progressive commitment. Use when reviewing pages for conversion potential or when CTA copy feels generic.
1onboarding-flow
Design first-run experiences that create the aha moment fast. Reduces time-to-value by sequencing actions, progressive disclosure, and contextual guidance. Use when building signup flows, product tours, or empty states.
1user-psychology
Apply motivation, friction, and trust patterns to product decisions. Maps cognitive biases and behavioral triggers to specific UI and copy choices. Use when reviewing flows for drop-off points or when something feels right but doesn't convert.
1