Your Product Owner walks into refinement with 47 unvetted items stacked in the backlog. Your team spends the first 20 minutes just trying to understand what they're looking at. By the time you've sorted dependencies, estimated three items, and fielded two stakeholder questions, the meeting's half over and you've refined exactly nothing.
This is where AI prompts for backlog refinement stop being nice-to-have and start being necessary. Not to replace your team's judgment, but to compress the busywork that eats refinement time. The seven prompts below are structured around the actual rhythm of backlog work: planning the items upfront, executing the refinement session itself, reviewing what stuck and what didn't, and communicating status to stakeholders who need to know.
Each prompt includes a specific role assignment, context variables, and constraints so you're not just dumping data into a chatbot and hoping. You'll get back structured output you can actually use in your next sprint.
Backlog Item Intake and Prioritization
Use this when you've got a raw list of feature requests, bugs, and technical debt from various sources (Slack, email, customer feedback, your own observations) and need to shape it into something refinement-ready.
You are an experienced Product Owner with 8 years in Agile teams across SaaS and enterprise products. You understand how to balance customer value, technical feasibility, and business strategy.
Context: You're working with a [team size]-person Scrum team on [sprint length]-week sprints. The team's tech stack is [tech stack]. The organization's product maturity is [maturity level: early-stage startup / growth-phase / enterprise]. You have a raw list of potential backlog items from multiple sources (customer requests, bug reports, technical debt, strategic initiatives).
Task: Categorize and prioritize this list into a structured backlog intake, flagging dependencies and high-risk items for early discussion.
Constraints: Optimize for clarity over comprehensiveness. Surface any items that smell like "we don't actually know what this is yet." Avoid over-engineering the prioritization; use a simple framework (must-have, should-have, could-have, technical debt). Flag items that depend on external work or decisions.
Output format: A numbered list with these columns:
1. Item ID
2. Title (one-line)
3. Category (Feature / Bug / Technical Debt / Strategic)
4. Priority bucket (Must-Have / Should-Have / Could-Have)
5. Dependencies (if any, or "None")
6. Risk flag (High / Medium / None)
7. Estimated effort band (XS / S / M / L / XL)
Anti-patterns: Don't create vague priority scores like "7.5 out of 10." Don't assume technical feasibility without flagging it. Don't hide items that need clarification; call them out explicitly.
[Paste your raw backlog items here]
Variables to fill in
[team size]— number of developers (e.g., 5, 8, 12)[sprint length]— duration of your sprint in weeks, typically 1 or 2[tech stack]— your primary technology stack (e.g., React/Node.js, Python/Django, Java/Spring)[maturity level]— where your organization sits in product development, e.g., "early-stage startup" or "enterprise with legacy systems"
What to expect
You'll get back a structured table with each item slotted into priority buckets and effort bands. Items flagged as high-risk or dependent will surface naturally so you can address them first in refinement.
When to skip it
If your backlog is already well-organized and you're just refining a known set of items for the next sprint, skip this and move to Prompt 2. This one is for the intake phase when you're drowning in unstructured requests.
User Story Decomposition and Acceptance Criteria Generation
Use this when you have a large, fuzzy item ("Improve user onboarding" or "Redesign the dashboard") and need to break it into smaller, testable stories with clear acceptance criteria.
You are an experienced Scrum Master who has facilitated hundreds of story-writing sessions. You know how to spot vague language and push for testable, specific outcomes. You understand the difference between a story and a task.
Context: Your team has [team size] developers. Your sprint length is [sprint length] weeks. The user or stakeholder requesting this work is [stakeholder role/type]. The current system/feature [brief current state]. The team's Definition of Done includes [DoD elements: automated tests, code review, documentation, etc.].
Task: Break this large item into 3–5 smaller, independently valuable stories, each with acceptance criteria, and flag any stories that need spike work.
Constraints: Each story should fit comfortably into a single sprint. Optimize for independent value: each story should deliver something a user or operator can see or use. Avoid creating stories that are 100% blocked by another story. Surface dependencies clearly.
Output format:
For each story:
- Story title (one line)
- User story format: "As a [role], I want [action] so that [benefit]"
- Acceptance criteria (numbered list, each testable)
- Effort estimate (XS / S / M / L)
- Dependencies (if any)
- Spike needed? (Yes / No, and if yes, what's the question?)
Anti-patterns: Don't create stories that are just tasks ("Write the API endpoint"). Don't hide acceptance criteria in prose; make them checkboxes. Don't assume the team knows what "better" means; define it.
Large item to decompose:
[Paste the large item or epic description here]
Variables to fill in
[team size]— number of developers on your team[sprint length]— sprint duration in weeks[stakeholder role/type]— who requested this (e.g., "VP of Sales," "support team," "end user")[brief current state]— one sentence on what exists now[DoD elements]— what your team considers "done" (e.g., "unit tests, code review, deployed to staging")
What to expect
You'll get 3–5 user stories, each with a clear title, user story format, numbered acceptance criteria, and effort estimates. Stories that need investigation (spikes) will be flagged upfront so you can plan them.
When to skip it
If the item is already a well-formed story with acceptance criteria, you don't need this. Use it when you're staring at something like "Improve performance" or "Better mobile experience" and have no idea where to start.
Dependency and Impact Analysis for Sprint Planning
Use this before sprint planning to map out which items block which others, and what the ripple effects are if you delay or accelerate certain stories.
You are a technical lead with 10 years of experience in cross-functional product delivery. You're skilled at spotting hidden dependencies and understanding how changes in one area cascade through the system.
Context: Your team is [team size] people. You're planning a [sprint length]-week sprint. Your system architecture is [brief: microservices / monolith / hybrid]. Your team owns [scope: one service / multiple services / full stack]. External dependencies exist with [teams/systems: e.g., "payments team, analytics platform, third-party API"].
Task: Map the dependencies across these candidate stories, identify which ones are critical path, and flag any that could cause delays if underestimated or blocked.
Constraints: Optimize for sprint flow: identify which stories should be started first to unblock others. Surface external dependencies that aren't in your control. Flag any stories that have circular or complex dependencies (these are refinement red flags).
Output format:
- A dependency matrix (table or text): Story A blocks Story B, Story C is independent, etc.
- Critical path: The sequence of stories that, if delayed, delays the whole sprint
- Unblocking sequence: Recommended story start order
- External blockers: Any dependencies outside your team's control
- Risk flags: Stories with unclear or risky dependencies
Anti-patterns: Don't assume dependencies that don't exist. Don't hide external blockers; call them out so the Product Owner can engage stakeholders early. Don't recommend a sequence that's technically correct but socially impossible.
Candidate stories for this sprint:
[Paste the list of story titles you're considering]
Variables to fill in
[team size]— number of developers[sprint length]— sprint duration in weeks[brief: microservices / monolith / hybrid]— your system architecture[scope: one service / multiple services / full stack]— what your team owns[teams/systems: ...]— other teams or external systems you depend on
What to expect
You'll get a dependency map and a recommended start sequence that minimizes blocked time. External blockers will be called out so you can negotiate early.
When to skip it
If your sprint is straightforward and stories are mostly independent, you might not need this. Use it when you're planning a complex sprint or when you've had problems with blocked work in the past.
Refinement Discussion Facilitator
Use this during or just before a refinement meeting to generate focused discussion prompts that surface ambiguity and build team consensus on what a story actually means.
You are an experienced Scrum Master who runs tight, productive refinement sessions. You know how to ask questions that expose vagueness without making the Product Owner defensive. You understand that the goal of refinement is shared understanding, not perfect estimation.
Context: Your team is [team size] people. Refinement meetings are [meeting duration] minutes, held [meeting frequency]. The team's experience level is [experience: junior / mixed / senior]. The Product Owner's communication style is [style: detailed / high-level / data-driven]. The team has struggled with [past refinement issues, if any: e.g., "unclear acceptance criteria," "underestimating complexity"].
Task: Generate 5–7 focused discussion questions for this story that will surface ambiguity and build team consensus on scope, effort, and risk.
Constraints: Questions should be open-ended but not rambling. Avoid yes/no questions. Surface technical assumptions. Flag any acceptance criteria that seem testable only in hindsight. Optimize for time: these questions should fit in a 10–15 minute story discussion.
Output format:
For each question:
- The question itself (phrased for the team to discuss)
- Why it matters (one sentence on what assumption or risk it uncovers)
Anti-patterns: Don't ask questions the Product Owner has already answered. Don't ask questions that only the tech lead can answer; save those for a spike. Don't assume the team understands the business context.
Story to refine:
[Paste the story title, description, and current acceptance criteria here]
Variables to fill in
[team size]— number of developers[meeting duration]— length of your refinement sessions in minutes[meeting frequency]— how often you refine (e.g., "weekly," "every other day")[experience: junior / mixed / senior]— your team's general seniority[style: detailed / high-level / data-driven]— how your Product Owner usually communicates[past refinement issues, if any]— problems you've had before (leave blank if none)
What to expect
You'll get 5–7 discussion prompts that expose ambiguity without derailing the meeting. Each question will surface a specific assumption or risk.
When to skip it
If the story is crystal clear and your team has asked all the obvious questions, you don't need this. Use it when a story is vague, or when your team tends to estimate first and ask questions later.
Estimation Sanity Check and Effort Banding
Use this after your team has estimated a set of stories to catch outliers, inconsistencies, and estimates that smell wrong.
You are a Scrum Master with 12 years of experience. You've seen teams chronically underestimate, overestimate, and estimate the same type of work wildly differently. You know how to spot when a story is underestimated because it's actually three stories in one.
Context: Your team uses [estimation method: planning poker / t-shirt sizing / story points]. Your typical sprint velocity is [velocity: e.g., "28 points," "8–10 medium stories"]. The team's estimation has historically been [accuracy: accurate / tends to underestimate / tends to overestimate]. Your sprint capacity is [capacity: e.g., "4 developers, 10 days available after meetings"].
Task: Review these estimates for consistency, flag outliers, and identify stories that might be underestimated or mislabeled.
Constraints: Optimize for sprint success: flag stories that, if underestimated, will blow your sprint. Surface stories that are estimated differently than similar past work. Don't assume the estimates are wrong; assume they need discussion.
Output format:
- Stories that are consistent with similar past work (no flag)
- Stories that are outliers (flag: why?)
- Stories that might be hiding multiple stories (flag: suggest decomposition)
- Recommended capacity check: "Your current estimates total [X] points/stories. Your typical velocity is [Y]. You're [safe / at risk / over capacity]."
Anti-patterns: Don't re-estimate for the team. Don't assume a high estimate means the story is too big; it might just be complex or risky. Don't ignore stories that are estimated lower than similar past work without asking why.
Stories with estimates:
[Paste story title and estimate for each: e.g., "User login flow: 13 points", "Fix database timeout: 3 points"]
Variables to fill in
[estimation method: planning poker / t-shirt sizing / story points]— how your team estimates[velocity: e.g., "28 points"]— your typical sprint velocity[accuracy: accurate / tends to underestimate / tends to overestimate]— your team's estimation track record[capacity: e.g., "4 developers, 10 days available after meetings"]— how much capacity you have this sprint
What to expect
You'll get a list of estimates flagged for consistency, outliers called out with reasoning, and a capacity check so you know whether you're planning a realistic sprint.
When to skip it
If your team has a strong estimation track record and you're confident in the numbers, you can skip this. Use it when you're planning a complex sprint, or when you've had estimation surprises in the past.
Backlog Health and Refinement Quality Review
Use this at the end of a sprint (or monthly) to audit whether your backlog items are actually ready for development and whether your refinement process is working.
You are an experienced Scrum Master who has coached teams on backlog hygiene and refinement discipline. You know the difference between a backlog that's been refined and one that's just been groomed.
Context: Your team has been refining for [duration: e.g., "3 sprints," "6 months"]. Your Definition of Ready includes [DoR elements: e.g., "acceptance criteria written," "dependencies identified," "estimated," "no blockers"]. In the last [sprint count: e.g., "3"] sprints, you've had [issues: e.g., "stories pulled mid-sprint because they weren't ready," "estimates were consistently off," "acceptance criteria were unclear"].
Task: Review your backlog against your Definition of Ready. Identify which items are truly ready, which need more refinement, and which should be rejected or sent back to the Product Owner.
Constraints: Be honest about what "ready" means in your context. Optimize for sprint flow: flag items that will cause rework or blocked time if pulled into a sprint. Surface patterns (e.g., "all the infrastructure stories are underestimated") so you can fix the process, not just the items.
Output format:
- Stories that meet your Definition of Ready (no action needed)
- Stories that are almost ready (flag: what's missing?)
- Stories that should be rejected or sent back (flag: why?)
- Pattern analysis: Common gaps in your refinement (e.g., "acceptance criteria are vague," "dependencies aren't identified early")
- One process recommendation: What to change in your next refinement cycle
Anti-patterns: Don't let perfect be the enemy of good; not every story needs 100% clarity before sprint start. Don't hide process problems by just re-refining items. Don't assume the Product Owner is the bottleneck without checking your own refinement discipline.
Backlog items to review:
[Paste story titles, current status, and any notes on why they're in the backlog]
Variables to fill in
[duration: e.g., "3 sprints"]— how long your team has been refining[DoR elements: e.g., "acceptance criteria written"]— what your Definition of Ready requires[sprint count: e.g., "3"]— how many recent sprints to analyze[issues: e.g., "stories pulled mid-sprint"]— problems you've had recently
What to expect
You'll get a clear view of which backlog items are actually ready, which need work, and which should be rejected. You'll also get one concrete process recommendation to improve future refinement.
When to skip it
If your backlog is small and you refine everything just-in-time, you might not need this. Use it when your backlog is large, or when you've had recurring issues with unready stories.
Stakeholder Communication and Status Reporting
Use this to generate clear, concise backlog status updates for stakeholders who need to know what's coming but don't need the details.
You are an experienced Product Manager who translates technical backlog work into business language. You know how to highlight what matters to stakeholders (timeline, risk, business value) without overwhelming them with estimation details.
Context: Your stakeholders are [stakeholder types: e.g., "executive sponsors," "customer success team," "finance"]. They care most about [priorities: e.g., "timeline," "risk," "business impact"]. Your backlog currently contains [backlog size: e.g., "47 items"] across [time horizon: e.g., "next 2 quarters"]. Recent changes to the backlog or priorities are [recent changes, if any].
Task: Generate a stakeholder-friendly backlog status report that shows what's coming, what's at risk, and what decisions need to be made.
Constraints: Use business language, not technical jargon. Highlight trade-offs (speed vs. quality, scope vs. timeline). Flag any decisions that need stakeholder input. Optimize for clarity: one page or less.
Output format:
- Executive summary (3–4 sentences on the state of the backlog)
- Top priorities for the next [time period: e.g., "quarter"] (3–5 items with business impact)
- At-risk items or decisions (if any)
- Decisions needed from stakeholders (if any)
- Timeline snapshot (when major features will ship, if known)
Anti-patterns: Don't use story points or technical estimates; translate to business outcomes. Don't hide risks; flag them clearly. Don't make promises about dates you can't keep.
Current backlog and recent changes:
[Paste a summary of your top 10–15 backlog items, priorities, and any recent changes]
Variables to fill in
[stakeholder types: e.g., "executive sponsors"]— who you're reporting to[priorities: e.g., "timeline, risk, business impact"]— what matters to them[backlog size: e.g., "47 items"]— how many items you're tracking[time horizon: e.g., "next 2 quarters"]— the planning window[recent changes, if any]— what's shifted in the backlog recently[time period: e.g., "quarter"]— your reporting period
What to expect
You'll get a one-page status report that translates your backlog into business outcomes. Risks and decisions will be surfaced clearly so stakeholders can engage without micromanaging.
When to skip it
If your stakeholders are deeply technical and want to see the backlog directly, you might not need this translation layer. Use it when you're reporting to non-technical leadership or when you need to justify backlog decisions.
How to Adapt These Prompts for Your Team
These seven prompts are starting points, not gospel. Your team's context is different: maybe you work in a regulated industry where every story needs audit trails, or you're in a startup where you ship twice a day. Read through each prompt, identify the variables that matter for your situation, and fill them in once. Save the filled-in versions as templates in your favorite AI tool (Claude, ChatGPT, whatever your team uses) so you're not retyping context every time.
The real power isn't in the prompts themselves. It's in building a backlog refinement rhythm where you use AI to compress the busywork (intake, decomposition, dependency mapping, sanity checks) so your team has more time for the thinking that only humans can do: deciding what actually matters, understanding what customers need, and building consensus on the hard trade-offs.
If you're refining backlog items regularly and want to go deeper on how to structure this work across your Product Owner and team, consider ThinkLouder's AI for Product Owners micro-credential, which covers backlog prioritization, AI-assisted analysis, and decision-making frameworks. Or if you're a Scrum Master looking to coach your team on refinement discipline, our Certified Scrum Master training includes a full module on backlog health and refinement facilitation.
Start with Prompt 1 next time you've got a raw intake of requests. See what you get back. Adjust the variables based on what works for your team. Then move through the others as your refinement process matures.
One short email, every other Friday. Real-world Scrum lessons, no fluff. Unsubscribe anytime.