Your backlog is three weeks behind. Stories are vague. Dependencies are buried in Slack threads. Your developers keep asking clarifying questions mid-sprint, and your Product Owner is drowning in email trying to answer them all.
Backlog refinement should prevent this. But most teams either skip it, rush it, or turn it into a spec-writing session that kills momentum. The real work of refinement is understanding the problem, not documenting a solution. That's where AI prompts come in—not to replace judgment, but to structure the conversation so your team actually has one.
Here are seven backlog refinement AI prompts, grouped by workflow: planning (how you frame the work), execution (how you run the meeting), review (how you assess what you've done), and communication (how you keep everyone aligned). Each prompt is built to be filled in with your team's specifics, run through an AI tool, and used as a starting point for discussion—not as a finished artifact.
Identifying and Prioritizing Backlog Items
Use this when you're staring at a pile of incoming requests and need to decide what actually matters. This prompt helps you surface the real problem behind each request so you can sort by impact, not just urgency.
You are an experienced Product Owner with 12 years of managing backlogs across [industry/domain]. Your job is to help identify which incoming requests should enter the backlog and in what order.
Context: Our team is [team size] developers, we work in [sprint length]-week sprints, and we're building [brief product description]. Right now we have [current backlog size] items in the backlog. Our last three sprints completed [X] story points on average.
Task: Analyze these incoming requests and rank them by impact on our product strategy, user pain, and team capacity.
Constraints: Prioritize requests that solve a repeated user problem or remove a bottleneck. Surface any requests that sound urgent but are actually low-impact. Flag requests that depend on other work already in the backlog. Do NOT assume all requests are equally valid—push back on vague ones.
Output format: Provide a numbered list with these columns: Request Name | User Impact (High/Medium/Low) | Effort Estimate (XS/S/M/L) | Dependencies | Recommended Action (Add to backlog now / Discuss with stakeholder / Defer)
Anti-patterns: Avoid saying "this is important because the stakeholder said so." Instead, explain why the user or the product benefits. Do not rank by request date or requestor seniority.
[Paste your incoming requests here, one per line. Include who requested it and why.]
Variables to fill in
[industry/domain]— your product category or market (e.g., "SaaS HR platforms," "healthcare compliance software")[team size]— number of developers on your team, typically 3–9[sprint length]— your sprint duration in weeks, typically 1 or 2[brief product description]— one sentence on what your product does[current backlog size]— approximate number of items in your backlog[X]— your team's average sprint velocity in story points
What to expect
You'll get a ranked list with explicit reasoning for each placement. The output will call out which requests are actually dependencies of work already in your backlog, and which ones are worth a conversation with stakeholders before you commit.
When to skip it
Skip this if your backlog is already stable and you're only adding 1–2 items per sprint. Use it when you're fielding a lot of incoming work and need to cut through the noise.
Structuring User Stories for Refinement
Use this when a story is too big, too vague, or missing the "why." This prompt helps you break down a story into pieces your team can actually discuss and estimate in refinement.
You are an experienced Scrum Master with 15 years of running refinement sessions. Your role is to help structure user stories so they're concrete enough to discuss, but not so detailed that they read like a spec.
Context: Our team is [team size] people, mostly [tech stack/skill level]. We use [estimation method: story points / t-shirt sizing / hours]. Our refinement sessions are [meeting length] minutes, and we typically refine [number of stories] stories per session.
Task: Take this raw story and break it into a well-formed story with acceptance criteria, dependencies, and a clear "why."
Constraints: The story should be completable in one sprint. Acceptance criteria should describe what "better" looks like, not how to build it. Flag any technical unknowns that need a spike. Do NOT write a technical specification.
Output format: Provide the refined story in this structure:
- Story Title
- User Story statement ("As a [role], I want [action], so that [benefit]")
- Why this matters (one sentence on user pain or business impact)
- Acceptance Criteria (3–5 bullets, each starting with a verb)
- Dependencies (if any)
- Technical Unknowns (if any)
- Estimated Complexity (XS / S / M / L / XL)
Anti-patterns: Avoid acceptance criteria that start with "the developer should..." or "the system should..." Write from the user perspective. Do not include implementation details like "use REST API" or "cache the result." Do not create criteria so detailed that a developer never needs to ask a question.
[Paste the raw story or request here.]
Variables to fill in
[team size]— number of people on your team[tech stack/skill level]— your primary technology and team experience (e.g., "React and Node.js, mid-level," "Python/Django, senior")[estimation method]— how your team sizes work (e.g., "story points," "t-shirt sizing")[meeting length]— your refinement session duration in minutes, typically 45–90[number of stories]— how many stories you typically refine per session, typically 3–8
What to expect
You'll get a story that's ready to bring into refinement. It'll have clear acceptance criteria (not a spec), and it'll surface any dependencies or unknowns your team needs to discuss before committing.
When to skip it
Skip this if the story is already well-formed and your team has already discussed it. Use it when a story is vague, too large, or missing context.
Surfacing Dependencies and Timeline Impacts
Use this when you're worried about hidden dependencies or when you need to explain to stakeholders why a story can't start next sprint. This prompt helps you map the work and surface what has to happen first.
You are an experienced product strategist with 10 years of managing release timelines and dependencies across distributed teams. Your job is to help identify which stories are blockers and which ones can run in parallel.
Context: Our team is [team size] developers across [timezone spread]. We work in [sprint length]-week sprints. Our current sprint ends [date]. We're planning to ship [feature name] by [target date].
Task: Map the dependencies for these stories and identify the critical path—the sequence of work that determines when we can ship.
Constraints: Surface any stories that block others. Flag any dependencies on external teams or systems. Identify stories that could run in parallel to save time. Do NOT assume stories can be parallelized if they share a developer or database. Be honest about what "done" means—if a story needs QA, design review, or stakeholder sign-off after dev, include that in the timeline.
Output format: Provide a dependency map in this format:
- Story Name → Blocks [Story Name, Story Name] → Blocked By [Story Name]
- Critical Path: [Sequence of stories that determines ship date]
- Parallelizable Work: [Stories that can run at the same time]
- External Dependencies: [Any blockers outside your team]
- Realistic Ship Date: [Date, with assumptions]
Anti-patterns: Do not assume "we can parallelize everything." Do not ignore design, QA, or stakeholder review as part of the timeline. Do not pretend a dependency doesn't exist because "the other team said they'd prioritize it."
[Paste your list of stories for this release. Include any known dependencies, external team involvement, or timeline constraints.]
Variables to fill in
[team size]— number of developers[timezone spread]— your team's timezone distribution (e.g., "all in US Eastern," "distributed across US and Europe")[sprint length]— sprint duration in weeks[date]— when your current sprint ends[feature name]— the feature or release you're planning[target date]— when you need to ship
What to expect
You'll get a clear critical path showing which stories have to happen first, which ones can run in parallel, and where external dependencies might slow you down. The output will include a realistic ship date with assumptions called out.
When to skip it
Skip this if you're working on isolated stories with no dependencies. Use it when you're planning a release or a multi-sprint feature.
Facilitating Refinement Discussion
Use this during your refinement meeting when a story is generating debate or when the team isn't clear on what "done" looks like. This prompt generates discussion prompts tailored to your story.
You are an experienced Scrum Master who has run 200+ refinement sessions. Your job is to help the team ask the right questions so they understand the story without turning refinement into a spec-writing session.
Context: Our team is [team size] people: [roles and experience levels]. This is our [frequency]-th refinement session this month. We typically spend [time per story] minutes per story.
Task: Generate five discussion questions that help the team understand this story's scope, constraints, and acceptance criteria without writing implementation details.
Constraints: Questions should be open-ended and invite the Product Owner to clarify, not close the conversation. Avoid questions that assume a technical solution. Surface any ambiguity in the acceptance criteria. Do NOT generate questions about how to code it.
Output format: Provide five numbered questions, each with a note on what the team should listen for in the answer.
Anti-patterns: Avoid "Can we use [technology] for this?" Avoid questions that start with "Should we...?" because they invite premature design decisions. Do not ask questions the acceptance criteria already answer.
[Paste the story and its acceptance criteria here.]
Variables to fill in
[team size]— number of people in refinement[roles and experience levels]— e.g., "5 developers (2 senior, 3 mid-level), 1 Product Owner, 1 QA engineer"[frequency]— how often you refine per month (e.g., "2nd," "3rd")[time per story]— how many minutes you spend per story, typically 8–15
What to expect
You'll get five concrete questions to ask in the room. Each one surfaces a specific part of the story that the team needs to understand before estimating.
When to skip it
Skip this if the story is simple and the team is already aligned. Use it when a story is generating confusion or when acceptance criteria are vague.
Suggesting Optimal Story Sizes and Estimation
Use this when you're not sure if a story is the right size for your sprint or when your estimates feel inconsistent. This prompt helps you calibrate.
You are an experienced Scrum Master with deep knowledge of estimation and sprint planning. Your job is to help teams right-size stories so they're completable in a sprint and estimable with confidence.
Context: Our team is [team size] developers. We work in [sprint length]-week sprints. Our average velocity is [velocity] story points per sprint. We use [estimation method]. In the last three sprints, we've completed [X, Y, Z] story points.
Task: Evaluate whether these stories are the right size for our sprint, and suggest how to split or combine them if needed.
Constraints: A story should be completable in 3–5 days by one developer, including testing and code review. If a story will take longer, it should be split. If a story is tiny (< 1 day of work), consider combining it with another. Surface any stories that are too vague to estimate.
Output format: For each story, provide:
- Story Name
- Current Estimate vs. Recommended Estimate
- Suggested Split (if too large) or Merge (if too small)
- Reasoning
Anti-patterns: Do not assume "we can parallelize to make it fit." Do not estimate based on wishful thinking—use your team's actual velocity. Do not combine stories that have different acceptance criteria or dependencies.
[Paste your list of stories with their current estimates.]
Variables to fill in
[team size]— number of developers[sprint length]— sprint duration in weeks[velocity]— your team's average story points per sprint[estimation method]— how you estimate (e.g., "story points," "t-shirt sizing")[X, Y, Z]— story points completed in your last three sprints
What to expect
You'll get a clear recommendation on which stories are too big or too small, and concrete suggestions on how to split or combine them. The output will reference your team's actual velocity, not a generic benchmark.
When to skip it
Skip this if your team is already comfortable with story sizing and consistently completes their sprint commitments. Use it when estimates feel all over the place or when you're consistently leaving work unfinished.
Evaluating Backlog Quality
Use this at the end of each sprint or monthly to assess whether your refinement work is actually paying off. This prompt helps you see where refinement is breaking down.
You are an experienced product operations leader who has helped teams improve their backlog health. Your job is to assess whether the backlog is ready for execution and where refinement is weak.
Context: Our team is [team size] developers. We refine [frequency] per [time period]. We've been using this refinement process for [duration]. In the last sprint, we completed [velocity] story points and had [number] stories that carried over to the next sprint.
Task: Evaluate the quality of our backlog by analyzing these metrics and stories. Identify which part of refinement is breaking down.
Constraints: Look for patterns: Are stories consistently underestimated? Are acceptance criteria vague? Are dependencies being missed? Do developers keep asking questions mid-sprint? Be honest about whether the problem is in refinement or in execution. Do NOT blame the team for poor refinement if they weren't given time to refine.
Output format: Provide a backlog health report with:
- Overall Health Score (1–10, with reasoning)
- Strengths (what refinement is doing well)
- Gaps (where refinement is breaking down)
- Recommended Changes (specific, actionable)
- Metrics to Track (to know if changes are working)
Anti-patterns: Do not say "refinement is bad" without naming the specific problem. Do not recommend changes that require more meetings—focus on better meetings. Do not ignore external factors like stakeholder churn or scope creep.
[Paste your sprint metrics, a sample of stories that were completed, and a sample of stories that carried over. Include any feedback from developers about clarity or missing information.]
Variables to fill in
[team size]— number of developers[frequency]— how often you refine (e.g., "twice")[time period]— the period for that frequency (e.g., "per sprint," "per month")[duration]— how long you've been using this refinement process[velocity]— story points completed last sprint[number]— stories that carried over
What to expect
You'll get a clear assessment of backlog health with specific gaps named. The output will tell you whether the problem is vague stories, missed dependencies, poor estimation, or something else entirely.
When to skip it
Skip this if you're running refinement for the first time. Use it after at least two sprints so you have data to analyze.
Generating Stakeholder Communication
Use this when you need to explain backlog status, priorities, or delays to stakeholders outside your team. This prompt helps you translate refinement work into language that executives and product leadership understand.
You are an experienced product communications specialist with 8 years of translating technical work into executive language. Your job is to help the team communicate backlog status and priorities to stakeholders.
Context: Our organization has [stakeholder groups: e.g., "C-suite, investors, customer success"]. They care most about [business outcomes: e.g., "time to market, customer retention, cost"]. Our team is [team size] and works in [sprint length]-week sprints. Right now we're working on [current initiative].
Task: Generate a stakeholder update that explains our backlog priorities, any delays or risks, and what we're shipping next.
Constraints: Use business language, not technical jargon. Be honest about trade-offs: if we're prioritizing [feature A], we're deferring [feature B]. Do NOT oversell timelines. Do NOT hide risks. Do NOT assume stakeholders understand story points or sprint velocity.
Output format: Provide an update in this structure:
- What We Shipped Last Sprint (business impact, not technical details)
- What We're Shipping This Sprint (business impact)
- Key Risks or Blockers (honest, with mitigation plan)
- What We're Deferring and Why (trade-off explanation)
- Timeline for [Next Major Release] (with confidence level and assumptions)
Anti-patterns: Do not say "we're blocked by another team" without explaining what that means for the stakeholder. Do not use terms like "velocity" or "story points" without defining them. Do not pretend a delay is a feature.
[Paste your backlog priorities, current sprint plan, and any known risks or delays. Include stakeholder questions or concerns from recent meetings.]
Variables to fill in
[stakeholder groups]— who you're communicating to (e.g., "C-suite," "board," "customer success team")[business outcomes]— what matters to them (e.g., "revenue," "customer retention," "speed to market")[team size]— number of developers[sprint length]— sprint duration in weeks[current initiative]— what your team is focused on[feature A]and[feature B]— specific features for the trade-off example[Next Major Release]— the next release or milestone stakeholders care about
What to expect
You'll get an update written in business language that explains priorities, trade-offs, and risks without hiding behind technical jargon. Stakeholders will understand what you're shipping, when, and why some things are being deferred.
When to skip it
Skip this if you have a dedicated product marketing or communications person. Use it when you need to talk to stakeholders directly about backlog and priorities.
How to Adapt These for Your Team
These seven prompts work best when you treat them as starting points, not finished products. After you run a prompt through your AI tool, bring the output into your refinement meeting and let your team react. The AI output surfaces structure and thinking; your team's judgment shapes the actual work.
For more on running effective refinement sessions and keeping your backlog healthy, check out our best tools for Scrum ceremonies and how AI tools for Product Owners can support your workflow. If you're looking to formalize these practices across your team, Scrum refinement techniques and the AI for Scrum Masters credential can help you scale consistent refinement patterns.
The goal isn't to automate refinement—it's to make the conversations faster and clearer so your team spends less time in meetings and more time shipping.
One short email, every other Friday. Real-world Scrum lessons, no fluff. Unsubscribe anytime.
