Your sprint planning meeting is running 90 minutes over. The team is stuck debating whether a story is 8 points or 13. The product owner hasn't clarified what "done" means for the new feature. And you're watching the clock because the developers need to start their work.
This is where sprint planning AI prompts come in. They're not here to replace your judgment or automate away the conversation. They're here to structure the conversation so it actually moves. A well-built prompt can help your team define realistic sprint goals, prioritize backlog items faster, estimate with fewer assumptions, and surface blockers before they become problems.
Here are seven prompts you can use throughout your sprint planning cycle, from goal-setting through execution monitoring. Each one is built with the constraints of a real Scrum team in mind: limited time, mixed technical backgrounds, and the need to move forward even when perfect clarity isn't available. Fill in the bracketed variables, paste your data into the prompt, and use the output to fuel your team conversation.
1. Sprint Goal Definition from Historical Data
Use this prompt at the start of sprint planning when your team needs to anchor on a realistic, measurable goal. It works best when you have 2-3 sprints of historical velocity or throughput data to work from.
You are an experienced Scrum Master with 8 years of experience running sprint planning sessions for distributed teams. Your role is to help teams set sprint goals that are ambitious but achievable, grounded in actual team capacity.
Context: Our team has [team size] developers, our sprint length is [sprint length] days, and we're working on [project or product name]. Over the last [number of sprints] sprints, our average velocity has been [velocity number] story points, or we completed an average of [number of items] items per sprint.
Task: Based on this historical performance, suggest 3 realistic sprint goals that align with our current backlog priorities and team capacity. Each goal should be measurable, completed within the sprint, and specific enough that the team can evaluate success at the sprint review.
Constraints: Avoid generic goals like "improve performance" or "build features." Each goal must reference a concrete outcome the team or stakeholders can observe. Flag any goal that assumes a productivity increase without evidence. Surface trade-offs: if the team commits to goal A, what gets deferred?
Output format: Provide 3 numbered goals. For each, include: the goal statement (one sentence), why it's realistic given our velocity, and one potential blocker to watch for.
Anti-patterns: Do not suggest goals that require the team to work overtime, pull in unestimated work, or depend on external dependencies outside the team's control.
[Paste your last 3 sprint summaries here, including items completed and velocity]
Variables to fill in
[team size]— the number of developers on your team, typically 3–9[sprint length]— your sprint duration in days, typically 10 or 14[project or product name]— the product or initiative your team is building[number of sprints]— how many completed sprints you want to analyze, typically 3–5[velocity number]— your team's average story points per sprint[number of items]— your team's average count of items completed per sprint
What to expect
You'll get 3 goal options with realistic context attached: why each one fits your capacity, and what could go wrong. Use these as starting points for your team conversation, not final decisions. The team should debate these and pick one (or combine elements from two).
When to skip it
If your team is brand new and has no velocity history, skip this prompt. Instead, ask the product owner to prioritize the top 5 backlog items, estimate them as a team using planning poker, and commit to completing the top 3–4. You'll build history over the first 2–3 sprints, then use this prompt going forward.
2. Backlog Prioritization with Stakeholder Alignment
Run this prompt during backlog refinement or just before sprint planning when you need to rank items by both value and complexity. It surfaces misalignment between what stakeholders think is important and what the team thinks is feasible.
You are a product strategist with 10 years of experience helping teams prioritize backlogs in fast-moving environments. Your job is to help teams and stakeholders agree on what matters most, given real constraints.
Context: Our team has [sprint length]-day sprints and can typically complete [velocity or item count] worth of work per sprint. Our current backlog has [number of backlog items] items. Key stakeholders care about: [list 2-3 business priorities, e.g., "reduce customer churn," "ship the new dashboard," "fix critical bugs"].
Task: Rank the top 10 backlog items by strategic value and team capacity fit. For each item, explain why it ranks where it does, what value it delivers, and what risk or dependency it carries.
Constraints: Prioritize based on both business value and technical feasibility. If an item is high-value but blocks other work, flag that. If an item is low-value but unblocks 3 other items, surface that trade-off. Do not assume the highest-value item is also the fastest to build.
Output format: Provide a numbered list of the top 10 items. For each item, include: rank, item name, estimated effort (if available), business value (high/medium/low), and one-sentence rationale for its position.
Anti-patterns: Do not rank items purely by business value and ignore team capacity. Do not recommend that the team "just work faster" to fit more in. Do not hide dependencies or risks.
[Paste your current backlog here, including item names, descriptions, and any existing estimates]
Variables to fill in
[sprint length]— your sprint duration in days[velocity or item count]— the amount of work your team typically completes per sprint, in story points or item count[number of backlog items]— how many items are currently in your backlog[list 2-3 business priorities]— the strategic goals your stakeholders have stated
What to expect
You'll get a ranked list with rationale. The ranking might surprise you: an item you thought was low-priority might move up because it unblocks other work, or a high-priority item might drop because it depends on something else finishing first. Use this as the foundation for your sprint planning conversation with stakeholders.
When to skip it
If your backlog is fewer than 10 items or your priorities are already crystal clear, you don't need this. But if you have 20+ items and stakeholders keep changing their minds about what matters, this prompt will save you hours of debate.
3. User Story Estimation with Assumption-Checking
Use this prompt when your team is estimating stories in sprint planning and you want to surface hidden assumptions before developers start work. It's especially useful for stories that have wide estimate ranges (some people say 3 points, others say 13).
You are an experienced technical lead who has run estimation sessions for [number of years] years. Your job is to help teams estimate stories accurately by surfacing the assumptions hidden in wide estimate ranges.
Context: Our team is estimating stories for a [sprint length]-day sprint. We work in [technology stack or domain, e.g., "React and Node.js," "data pipelines," "mobile iOS"]. Our team has [team size] developers with [experience level, e.g., "mixed experience, 2 seniors and 3 juniors"].
Task: For each story, identify the key assumptions baked into the estimates, flag any that are risky, and suggest questions the team should ask before committing.
Constraints: Focus on assumptions that could change the estimate by 5+ points. Ignore minor uncertainties. If the team is split (some say 5, others say 13), identify what's driving that split. Surface dependencies on other teams, external systems, or unknowns.
Output format: For each story, provide: the story name, the estimate range given by the team, the top 3 assumptions driving that range, one question to ask the product owner or architect to validate each assumption, and a recommended estimate after assumptions are addressed.
Anti-patterns: Do not just average the estimates (e.g., 5 + 13 = 9). Do not ignore wide ranges. Do not recommend an estimate without surfacing the assumptions that support it.
[Paste the stories being estimated here, including any existing estimates from team members]
Variables to fill in
[number of years]— your experience level, e.g., "8"[sprint length]— your sprint duration in days[technology stack or domain]— the tech or business domain your team works in[team size]— number of developers[experience level]— a brief description of your team's seniority mix
What to expect
You'll get a breakdown of the assumptions hiding in your estimate ranges. You'll see which questions to ask before committing. Most teams find that once they answer 2–3 clarifying questions, the estimate range tightens significantly. The team can then commit with confidence.
When to skip it
If your team's estimates are already tight (everyone says 5, or everyone says 8), you don't need this. Use it when estimates are scattered or the team is clearly uncertain.
4. Task Breakdown and Dependency Mapping
Run this prompt after you've committed to stories in sprint planning. It helps you break stories into concrete tasks, identify who should do what, and surface blockers before the sprint starts.
You are a technical project coordinator with 12 years of experience breaking down stories into executable tasks for software teams. Your job is to help teams think through all the work hidden inside a story, including testing, documentation, and integration.
Context: Our team has [team size] developers. Team strengths: [list 2-3 specialties, e.g., "Alice does backend APIs, Bob handles database migrations, Carol owns frontend"]. Our sprint starts [date] and ends [date]. We have [number of] existing systems or services this story touches.
Task: Break down each story into concrete tasks. For each task, suggest who should own it based on team strengths, identify any dependencies or blockers, and flag anything that needs to happen before development can start.
Constraints: Include testing, documentation, and deployment work as explicit tasks, not afterthoughts. If a task depends on another team (e.g., DevOps, design), flag it and estimate the wait time. Avoid assigning all tasks to the strongest developer; use this as a chance to build skills across the team.
Output format: For each story, provide a task list in order of execution. Include: task name, owner (or "TBD if no clear owner), estimated hours, dependencies (if any), and one-sentence description of what "done" means for that task.
Anti-patterns: Do not hide testing or documentation work. Do not assume all tasks can happen in parallel. Do not assign risky or unfamiliar work to the most junior developer without pairing.
[Paste the committed stories here, with story descriptions and acceptance criteria]
Variables to fill in
[team size]— number of developers[list 2-3 specialties]— the key skills or specialties on your team[date]— the sprint start date[date]— the sprint end date[number of]— how many systems or services the story touches
What to expect
You'll get a task breakdown with owners and dependencies mapped out. Use this in your sprint kickoff to make sure everyone knows what they're doing and what's blocking them. If a dependency is external (waiting for design review, waiting for another team), you'll see it now, not on day 3 of the sprint.
When to skip it
If your team is highly experienced and breaks down stories on their own, you might not need this. But if you have new team members, high turnover, or stories that touch multiple systems, this prompt will save you from surprises mid-sprint.
5. Daily Standup Focus and Blocker Surfacing
Use this prompt to structure your daily standup so it surfaces real blockers instead of becoming status theater. Run it at the start of each day during the sprint.
You are an experienced Scrum Master who has run standups for [number of years] years across [team types, e.g., "distributed teams in 3 time zones," "co-located teams," "hybrid teams"]. Your job is to help the team focus on progress, blockers, and next steps, not status updates.
Context: Our team has [team size] developers. Our sprint goal is: [sprint goal]. Today is day [day number] of [sprint length]. We use [standup format, e.g., "15-minute synchronous standup," "async Slack updates," "hybrid with a 10-minute sync"].
Task: Generate 5 focused standup questions that help the team surface real blockers, celebrate progress, and identify what needs to happen today. Each question should take less than 2 minutes per person to answer.
Constraints: Avoid generic status questions like "What did you do yesterday?" Focus on progress toward the sprint goal, not task completion. If someone is blocked, surface it in the first 30 seconds so the team can swarm. Do not let standups run over 15 minutes.
Output format: Provide 5 numbered questions. For each, include the question, why it matters, and what kind of answer signals a blocker that needs immediate attention.
Anti-patterns: Do not ask for detailed status updates. Do not let standups become planning sessions. Do not ignore blockers; surface them and schedule a separate conversation if needed.
[Paste your sprint goal and current task list here]
Variables to fill in
[number of years]— your experience as a Scrum Master[team types]— the type of team (distributed, co-located, hybrid, etc.)[team size]— number of developers[sprint goal]— the goal your team committed to for this sprint[day number]— which day of the sprint it is[sprint length]— your sprint duration in days[standup format]— how your team runs standups (sync, async, hybrid)
What to expect
You'll get 5 tight questions designed to surface blockers in the first few minutes. Use these instead of the default "What did you do, what will you do, any blockers?" You'll find that blockers surface faster and the team can address them immediately instead of discovering them at day 5.
When to skip it
If your team's standups are already tight and blockers are surfacing, you don't need this. Use it if standups are running long, feeling like status theater, or if blockers are being discovered too late.
6. Sprint Review Preparation and Feedback Capture
Run this prompt 1–2 days before your sprint review to help the team prepare a focused demo and gather meaningful stakeholder feedback.
You are an experienced product facilitator who has run sprint reviews for [number of years] years. Your job is to help teams prepare for reviews that generate useful feedback instead of just showcasing completed work.
Context: Our sprint goal was: [sprint goal]. We completed [number of items] items this sprint. Our sprint review is [date and time]. We expect [number of stakeholders] stakeholders, including [stakeholder roles, e.g., "the CEO, two product managers, and customer support"].
Task: Design a sprint review agenda that takes [review length, e.g., "45 minutes"] and focuses on the sprint goal, completed work, and specific feedback questions for stakeholders. For each completed item, suggest what to demo and what question to ask stakeholders.
Constraints: Spend no more than [demo time per item, e.g., "3 minutes"] demoing each item. Save time for questions and feedback. If an item is incomplete or partially done, decide whether to demo it or skip it. Frame questions so stakeholders give specific feedback, not just "looks good."
Output format: Provide a sprint review agenda with: time allocations, what to demo for each item, one specific feedback question per item, and 2–3 questions about the sprint goal and team process.
Anti-patterns: Do not spend 30 minutes demoing one feature. Do not ask vague questions like "What do you think?" Do not skip the sprint goal; review it explicitly.
[Paste your completed items, partially completed items, and sprint goal here]
Variables to fill in
[number of years]— your experience running reviews[sprint goal]— the goal your team committed to[number of items]— how many items the team completed[date and time]— when your sprint review is scheduled[number of stakeholders]— how many people will attend[stakeholder roles]— who will be there (CEO, PMs, support, etc.)[review length]— how long your sprint review is, typically 30–60 minutes[demo time per item]— how much time to spend on each demo, typically 2–5 minutes
What to expect
You'll get a structured agenda that fits your time and surfaces the feedback you actually need. Instead of a 60-minute demo where half the room checks out, you'll have a focused 45 minutes with specific questions that help stakeholders think through what they saw.
When to skip it
If your sprint reviews are already focused and generating good feedback, you don't need this. Use it if reviews feel rushed, stakeholders give vague feedback, or you're not sure what to demo.
7. Retrospective Insights and Action Item Tracking
Run this prompt after your sprint retrospective to synthesize what the team learned and make sure action items actually get done in the next sprint.
You are an experienced Agile coach who has facilitated retrospectives for [number of years] years. Your job is to help teams turn retrospective insights into concrete actions that actually happen, not just good intentions.
Context: Our team is [team size] developers. This retrospective focused on: [retro topic or format, e.g., "what went well, what didn't, what to improve," "the sailboat format"]. Our sprint goal was [sprint goal]. We completed [number of items] items.
Task: Synthesize the retrospective notes into 3–5 specific, actionable improvements for the next sprint. For each action, identify who owns it, when it will happen, and how the team will know it worked.
Constraints: Focus on actions the team can control and complete in one sprint. Avoid vague improvements like "communicate better." If an action requires support from outside the team (e.g., management, another team), flag it and suggest a concrete ask. Prioritize actions that will unblock the most pain.
Output format: Provide 3–5 numbered actions. For each, include: the action (one sentence), the owner, when it happens (e.g., "sprint planning," "daily"), success metric (how you'll know it worked), and one potential blocker.
Anti-patterns: Do not recommend actions that require the team to work more hours. Do not suggest actions that depend entirely on management buy-in without a clear ask. Do not lose the action items after the retrospective; track them.
[Paste your retrospective notes here, including what went well, what didn't, and improvement suggestions]
Variables to fill in
[number of years]— your experience facilitating retros[team size]— number of developers[retro topic or format]— what your retro focused on or what format you used[sprint goal]— the goal from the sprint you're reflecting on[number of items]— how many items the team completed
What to expect
You'll get 3–5 concrete actions with owners and success metrics. Instead of a list of vague improvements that disappear after the retro, you'll have specific work that the team commits to in the next sprint. Track these actions on your sprint board so they don't get lost.
When to skip it
If your retrospectives already produce concrete actions and your team tracks them through the next sprint, you don't need this. Use it if retro insights tend to evaporate or if you're not sure how to turn feedback into action.
How to Adapt These Prompts for Your Team
These seven prompts work for most Scrum teams, but your context is unique. Adjust the variables, add your team's specific constraints (e.g., "we work in a highly regulated environment" or "we have a 24-hour deploy window"), and test them in one sprint before rolling them out.
If you're new to using AI in your sprint planning cycle, start with prompt 1 (sprint goal definition) and prompt 3 (estimation assumption-checking). Those two alone will tighten your planning and surface blockers early. Once you're comfortable with those, add the others.
For more on running effective sprint planning and other Scrum ceremonies, check out our best tools for Scrum ceremonies guide, which covers the tools and practices that actually support better facilitation. If you're a product owner looking to sharpen your backlog work, our AI tools for product owners post covers seven practical applications beyond the hype.
And if you're serious about building AI fluency into your Scrum practice, consider the AI for Scrum Masters micro-credential, launched by Scrum Alliance in October 2024. It teaches you to use AI tools in ceremonies and decision-making without replacing the human judgment that makes Scrum work.
If your team is ready to level up your sprint planning and certification, explore ThinkLouder's CSM and CSPO training programs or view our upcoming schedule to find a class that fits your timeline.
One short email, every other Friday. Real-world Scrum lessons, no fluff. Unsubscribe anytime.
