Your team just finished a two-week sprint. The retrospective is scheduled for tomorrow afternoon. You know the format: what went well, what didn't, what we'll do differently. By hour two, the same people are talking, the quiet ones stay quiet, and you leave with action items nobody remembers by Wednesday.
AI prompts won't fix a broken retrospective culture, but they will help you surface the patterns your team is already living through. They'll push past surface-level complaints. They'll make it safer for people to say what they actually think. And they'll give you something concrete to track.
Here are seven prompts, structured for planning, execution, review, and follow-through. Each one is built to work in real Scrum teams, not hypothetical ones. Use them as written first. Then adapt them to your team's size, maturity, and what you've learned from the last three retros.
Retrospective Agenda Builder Based on Sprint Health Signals
Use this at the start of retro planning when you want to skip the generic "what went well" format and focus the discussion on what actually mattered this sprint.
You are an experienced Scrum Master with 12 years of team facilitation experience. Your role is to design a focused retrospective agenda that surfaces the real friction points without wasting time on surface-level discussion.
Context: A [team size]-person Scrum team just completed a [sprint length]-day sprint. The sprint had [number of completed items] completed items, [number of incomplete items] incomplete items, and [one sentence describing the main blocker or win].
Task: Build a 60-minute retrospective agenda that prioritizes the issues most likely to affect the next sprint's velocity and team morale.
Constraints: Assume the team has [team experience level: new/intermediate/mature] Scrum experience. Avoid generic icebreakers. Focus on actionable patterns, not feelings. Surface one trade-off the team should discuss explicitly. Do not suggest more than 3 discussion topics.
Output format: Numbered list with time allocations (in minutes), topic name in bold, and one-sentence facilitator note for each segment.
Anti-patterns: Do not suggest activities that require special materials or prep. Do not assume the team wants to celebrate; focus on what blocks progress. Do not create a "parking lot" without a specific follow-up plan.
[Paste your sprint metrics, blockers, and team context here]
Variables to fill in
[team size]— number of people on the Scrum team, typically 3–9[sprint length]— your sprint duration in days, typically 10 or 14[number of completed items]— count of items marked Done in the sprint[number of incomplete items]— count of items still in progress or not started[one sentence describing the main blocker or win]— e.g., "database migration took twice as long as expected" or "we shipped the payment feature two days early"[team experience level: new/intermediate/mature]— how long the team has been running Scrum together
What to expect
You'll get a time-boxed agenda with 2–3 focused discussion topics, each tied to a specific sprint outcome. The agenda will name one explicit trade-off to surface (e.g., "velocity vs. technical debt") so the team doesn't pretend both are equally solvable right now.
When to skip it
Skip this if your retrospective is already well-structured and your team consistently surfaces their own priorities. Use it when retros feel repetitive, when the same issues come up every sprint with no resolution, or when you're onboarding a new team member who needs to see how your retro rhythm works.
Safe Space Facilitator for Psychological Safety in Retros
Use this prompt when you sense that people aren't saying what they actually think, or when you know there's tension between certain team members that won't surface in the standard retro format.
You are a Scrum Master with a background in team dynamics and psychological safety. Your job is to generate facilitation prompts that help team members speak honestly without fear of judgment or repercussion.
Context: A [team size]-person team is in a retrospective. The team has [describe team dynamics: e.g., "new members who are still finding their voice," "recent conflict between frontend and backend developers," "fear of speaking up to senior engineers"].
Task: Generate 4–5 open-ended questions and one anonymous feedback mechanism that will help quieter or more cautious team members contribute their real perspective.
Constraints: Avoid questions that can be answered "yes" or "no." Do not put anyone on the spot or ask for public commitments. Ensure at least one question invites people to name something they're worried about. Do not assume the team wants to be vulnerable; offer a low-risk entry point.
Output format: Numbered list of 4–5 questions (each 1–2 sentences), followed by one anonymous collection method (e.g., written sticky notes, Slack poll, Google form) with setup instructions in 2–3 sentences.
Anti-patterns: Do not use corporate jargon like "synergy" or "alignment." Do not ask "How are you feeling?" without context. Do not require people to share in real-time if they haven't opted in. Do not assume silence means agreement.
[Paste your description of the team dynamic or specific tension you want to surface here]
Variables to fill in
[team size]— number of people on the Scrum team[describe team dynamics: e.g., ...]— specific context about what's preventing honest conversation (e.g., "new members who are still finding their voice," "recent conflict between frontend and backend developers," "one person dominates every meeting")
What to expect
You'll receive 4–5 targeted questions designed to lower the barrier to speaking up, plus one low-pressure anonymous mechanism (like written cards or a private poll) that gives people a way to contribute without live exposure. The questions will be concrete, not therapeutic.
When to skip it
Skip this if your team already has strong psychological safety, speaks freely in retros, and doesn't have known conflict. Use it when you notice certain people staying quiet, when you've heard complaints in 1-on-1s that didn't surface in group settings, or after a sprint with visible tension.
Sprint Pattern Analyzer Using Historical Data
Use this after you've run 3–4 retrospectives with the same team and you want to surface recurring patterns that the team might not see on their own.
You are a data analyst who specializes in team performance patterns. Your role is to identify recurring issues and wins across multiple sprints, and highlight which patterns are worth addressing versus which are noise.
Context: A [team size]-person Scrum team has completed [number of sprints] sprints over [time period: e.g., "3 months"]. The team works on [type of work: e.g., "backend services," "mobile app," "mixed frontend/backend"].
Task: Analyze the retrospective notes from the past [number of sprints] sprints and identify 3–4 patterns: recurring blockers, recurring wins, and one pattern that's changing (improving or degrading).
Constraints: Distinguish between one-off issues and systemic patterns. Flag which pattern is most likely to hurt velocity if not addressed. Avoid blame; frame patterns as system issues, not individual failures. Do not suggest solutions yet; just name the patterns clearly.
Output format: Three sections: (1) Recurring Blockers (numbered list, each with sprint count and impact level), (2) Recurring Wins (numbered list, each with sprint count), (3) One Emerging Trend (1–2 sentences on what's changing). End with one question for the team to discuss.
Anti-patterns: Do not assume correlation is causation. Do not blame individuals. Do not suggest that patterns mean the team is failing. Do not ignore positive patterns; celebrate them as much as problems.
[Paste retrospective notes from your last 3–4 sprints here, in chronological order]
Variables to fill in
[team size]— number of people on the Scrum team[number of sprints]— how many past sprints you want to analyze, typically 3–5[time period: e.g., ...]— the calendar span those sprints cover[type of work: e.g., ...]— the domain or tech stack the team works on
What to expect
You'll get a clear breakdown of what's repeating (blockers, wins, and emerging shifts), with a count of how many sprints each pattern has shown up. The output will name one pattern as the highest priority to address, and will end with a discussion question for the team.
When to skip it
Skip this if you've only run one or two retrospectives with the team. Use it when you feel like the same issues keep coming up, when you want to prove to the team that a pattern is real (not just your perception), or when you're preparing for a team health conversation with leadership.
Action Item Prioritizer with Impact and Effort Scoring
Use this when your retrospective has generated a long list of action items and you need to help the team decide which ones actually matter and which ones are nice-to-haves.
You are a Scrum Master experienced in helping teams prioritize ruthlessly. Your role is to score proposed action items on impact and effort so the team can choose what to actually commit to.
Context: A [team size]-person team has identified [number of action items] potential action items from their retrospective. The team's capacity for change is [low/medium/high], meaning they can realistically implement [number of changes] changes this sprint without losing focus on development work.
Task: Score each action item on a 1–5 scale for impact (how much will this improve the next sprint?) and effort (how much time and coordination will this take?), then recommend which [number of changes] items to commit to.
Constraints: Assume the team is already at capacity with sprint work. Prioritize items that improve team velocity or morale directly. Do not recommend items that require approval from outside the team unless they're already approved. Flag any item that requires more than one person's time.
Output format: Table with columns: Action Item | Impact (1–5) | Effort (1–5) | Priority Rank | Owner. Below the table, list the top [number of changes] recommended items in bold, with one-sentence rationale for each.
Anti-patterns: Do not score everything as "high impact." Do not recommend items the team has already tried and abandoned. Do not assign ownership without checking if that person agreed. Do not ignore effort; an item with high impact and high effort might not be the right choice right now.
[Paste the list of action items from your retrospective here]
Variables to fill in
[team size]— number of people on the Scrum team[number of action items]— how many potential action items the team identified[low/medium/high]— the team's realistic capacity for implementing changes[number of changes]— how many action items you want to commit to (typically 1–3)
What to expect
You'll get a prioritized table with impact and effort scores for each action item, plus a clear recommendation on which 1–3 items to commit to this sprint. The output will flag which items have hidden effort (like needing approval or coordination across teams).
When to skip it
Skip this if your retrospectives generate only 1–2 action items and the team already knows which ones to prioritize. Use it when retros produce long lists that never get executed, when the team is overwhelmed, or when you want to show leadership why some good ideas have to wait.
Accountability Check-In Template for Tracking Action Items Across Sprints
Use this at the start of your next retrospective to review whether the action items from last sprint actually happened, and if not, why.
You are a Scrum Master who knows that action items die in the gap between retros. Your job is to create a check-in format that surfaces blockers to action item completion without blame.
Context: A [team size]-person team committed to [number of action items] action items in their last retrospective. The sprint just ended, and you're about to start the new retro.
Task: Generate a quick check-in format (5–10 minutes) that reviews each action item, determines if it was completed, and surfaces why incomplete items stalled.
Constraints: Keep this brief; don't let it become a blame session. Assume some items will be incomplete and that's normal. Focus on learning, not punishment. If an item is incomplete, surface the blocker, not the person. Do not skip this; incomplete items are data about what the team can realistically commit to.
Output format: A numbered list of 3–4 check-in questions per action item (yes/no or short-answer), followed by a template for capturing blocker reasons (e.g., "Blocked by dependency," "Deprioritized," "Unclear ownership") with a one-sentence follow-up for each reason.
Anti-patterns: Do not ask "Why didn't you do this?" Do not assume incomplete items mean the team is lazy or uncommitted. Do not skip this because it feels awkward. Do not let the same item roll over three sprints without changing your approach.
[Paste the list of action items from your previous retrospective here]
Variables to fill in
[team size]— number of people on the Scrum team[number of action items]— how many action items the team committed to last sprint
What to expect
You'll get a short check-in format that takes 5–10 minutes to run through, plus a blocker taxonomy (dependency, deprioritized, unclear ownership, etc.) so you can spot patterns in why items don't get done. The output will be factual, not emotional.
When to skip it
Skip this if your team consistently completes action items and you've never had carryover. Use it when you notice action items disappearing into a void, when the same issues come up in consecutive retros, or when you want to help the team be more realistic about what they can commit to.
Sentiment and Engagement Analysis from Retro Feedback
Use this when you want to understand the team's overall morale and engagement, not just what went right or wrong in the sprint.
You are a team health analyst with experience reading between the lines of retrospective feedback. Your role is to assess team sentiment and flag early warning signs of burnout, disengagement, or conflict.
Context: A [team size]-person team has just completed a retrospective. The sprint was [describe sprint: e.g., "high-pressure," "understaffed," "post-launch," "routine"]. The team's tenure together is [team tenure: e.g., "2 months," "1 year"].
Task: Analyze the retrospective feedback (notes, comments, tone) and provide a sentiment snapshot: overall morale, engagement level, and one early warning sign (if any).
Constraints: Look for patterns in language, not individual comments. Flag concerns without being alarmist. Distinguish between sprint fatigue (normal) and deeper disengagement (worth addressing). Do not pathologize healthy disagreement.
Output format: Three sections: (1) Overall Sentiment (one sentence), (2) Engagement Level (low/medium/high with 2–3 supporting observations), (3) Early Warning Signs (if any: list specific comments or patterns that suggest burnout, conflict, or disengagement, with one recommended follow-up conversation).
Anti-patterns: Do not assume negative comments mean the team is unhappy. Do not ignore positive signals. Do not recommend therapy or HR intervention unless the signal is severe. Do not share this analysis with the team without context; it's for your awareness as the Scrum Master.
[Paste the full retrospective notes, comments, and discussion summary here]
Variables to fill in
[team size]— number of people on the Scrum team[describe sprint: e.g., ...]— context about the sprint's difficulty or special circumstances[team tenure: e.g., ...]— how long the team has been working together
What to expect
You'll get a three-part snapshot of team health: overall morale, engagement level (with specific observations), and any early warning signs (like repeated complaints about one person, signs of burnout, or conflict). The output is for your awareness, not for sharing with the team.
When to skip it
Skip this if you already have strong intuition about your team's morale and you check in 1-on-1 with each person regularly. Use it when you manage multiple teams and want a quick health check, when you're new to the team and want to calibrate your understanding, or when you notice something feels off but can't name it.
Experiment Design for Next Sprint Based on Retro Insights
Use this at the end of your retrospective when you want to turn one action item into a small, testable experiment that the team will actually run.
You are a Scrum Master who designs small experiments to test new practices. Your role is to turn a retrospective insight into a concrete, time-boxed experiment that the team can run next sprint without derailing their work.
Context: A [team size]-person team identified a problem in their retrospective: "[Paste the problem or action item here]." The team has [team experience level] experience running experiments. The sprint is [sprint length] days long.
Task: Design a one-sprint experiment that tests one small change to address this problem. The experiment should be easy to run, easy to measure, and easy to abandon if it doesn't work.
Constraints: Keep the experiment to one change only. Do not require new tools or training. Assume the team will forget about it if it's not built into their daily rhythm. Make success measurable in 1–2 metrics. Do not commit the team to keeping the change forever; frame it as a test.
Output format: Experiment card with: (1) Hypothesis (one sentence: "If we [change], then [outcome] because [reason]"), (2) What Changes (2–3 sentences on the specific practice), (3) How We'll Measure It (1–2 metrics), (4) Time Box (days), (5) Check-In Point (when you'll review it), (6) Success Criteria (what counts as "this worked"), (7) Abort Criteria (what counts as "this isn't working, let's stop").
Anti-patterns: Do not design an experiment that requires buy-in from outside the team. Do not make it so ambitious that it becomes a project. Do not forget the abort criteria; teams need permission to stop. Do not run an experiment for more than one sprint without a checkpoint.
[Paste the retrospective problem or action item here]
Variables to fill in
[team size]— number of people on the Scrum team[Paste the problem or action item here]— the specific issue or action item from the retrospective[team experience level]— how many experiments or new practices the team has run before[sprint length]— your sprint duration in days
What to expect
You'll get a one-page experiment card with a clear hypothesis, a specific change, one or two measurable outcomes, and explicit abort criteria. The experiment is designed to run for exactly one sprint and be reviewed at a set checkpoint, so it doesn't become a permanent practice by accident.
When to skip it
Skip this if your team is already running regular experiments and you don't need a template. Use it when you want to make action items more concrete, when you want to test a change before committing to it, or when you're trying to build a culture of small, safe-to-fail improvements.
How to adapt these prompts for your team
These seven prompts are a starting point. The first time you use one, run it as written. Then watch what happens. Does the output match what your team actually needs? Did the AI miss a detail about your context? Adjust the context variables to be more specific. If the output is too generic, add one sentence to the CONSTRAINTS section that names what you want to avoid.
Your team's retrospectives are unique. A five-person startup team running two-week sprints has different needs than a 12-person enterprise team running one-week sprints. The prompts work best when you fill in the specific numbers and context, not when you leave them blank.
If you're new to running retrospectives or you want to make sure your team is getting the most from them, consider Certified Scrum Master training. A CSM course will give you the foundation to run retros that actually change how your team works, and AI prompts become a tool on top of that foundation, not a replacement for it.
Start with one prompt next retrospective. See what shifts.
One short email, every other Friday. Real-world Scrum lessons, no fluff. Unsubscribe anytime.