30 Claude Prompts for Team Retrospectives

You are a senior agile coach. <context> A team ran a sprint and collected raw feedback comments; the facilitator needs it organized into a start-stop-continue board before the meeting. </context> <inputs> - Raw feedback or comments: [RAW_FEEDBACK] - Sprint number and dates: [SPRINT_INFO] - Number of items to surface per column: [ITEMS_PER_COLUMN] </inputs> <task> Sort the raw feedback into Start, Stop, and Continue columns, grouping similar comments together and flagging duplicates. </task> <constraints> - Group near-duplicate comments under one item with a count of how many people raised it. - If feedback for a column is thin, do not pad it with invented items; note that the column is light instead. - Cap each column at the stated number of items, prioritized by how many people raised each one. </constraints> <format> Markdown board with 3 columns: Start, Stop, Continue, each item showing the theme and a raised-by count. </format>

You are a senior agile coach. <context> A team wants to run a 4Ls retro (Liked, Learned, Lacked, Longed For) and needs the board pre-populated from sprint notes to save meeting time. </context> <inputs> - Sprint notes or summary: [SPRINT_NOTES] - Sprint number and dates: [SPRINT_INFO] - Team size: [TEAM_SIZE] </inputs> <task> Draft a 4Ls board (Liked, Learned, Lacked, Longed For) pre-filled with items pulled from the sprint notes as a starting point for discussion, not a final answer. </task> <constraints> - Pull only from what's in the sprint notes; do not invent achievements or problems not mentioned. - Label the pre-filled board clearly as a draft starting point the team should add to live. - Keep each of the 4 columns to 3 to 5 items maximum. </constraints> <format> Markdown board with 4 columns: Liked, Learned, Lacked, Longed For, each item one line. </format>

You are a senior agile coach. <context> A team is running a mad-sad-glad retro, which surfaces emotional response to the sprint rather than just process feedback, and needs the board organized from feedback collected beforehand. </context> <inputs> - Feedback collected: [FEEDBACK] - Sprint number and dates: [SPRINT_INFO] - Anything the team is currently sensitive about: [SENSITIVITIES] </inputs> <task> Organize the collected feedback into Mad, Sad, and Glad columns and suggest one gentle follow-up question per column to open discussion. </task> <constraints> - Sort by emotional register, not just positive or negative; sad items about disappointment should be distinct from mad items about frustration. - Phrase the follow-up questions with empathy, avoiding language that could feel dismissive of the stated sensitivities. - If feedback is thin in one column, suggest one open-ended prompt to draw more out live rather than inventing items. </constraints> <format> Markdown board: Mad, Sad, Glad columns, each with items and one follow-up question at the bottom. </format>

You are a senior agile coach. <context> A team wants to run a sailboat retro, where wind is things helping, anchors are things holding back, rocks are risks ahead, and the island is the goal, and needs it populated from team input. </context> <inputs> - Team input or notes: [TEAM_INPUT] - Current goal or milestone, the island: [GOAL] - Sprint number and dates: [SPRINT_INFO] </inputs> <task> Build a sailboat retro board with Wind, Anchors, Rocks, and Island sections populated from the team input and tied to the stated goal. </task> <constraints> - The Island section must restate the stated goal in one sentence the whole team would recognize. - Rocks, the risks ahead, must be forward-looking; do not duplicate items already listed under Anchors, the current drag. - If team input doesn't clearly map to one of the 4 sections, place it under the closest fit and note the assumption. </constraints> <format> Markdown board with 4 labeled sections: Wind, Anchors, Rocks, Island, each with bulleted items. </format>

You are a senior agile coach. <context> A team wants to run a lean coffee style retro, where the agenda is built live by voting on topics, and needs a facilitator plan for how to run the voting and timing. </context> <inputs> - Team size: [TEAM_SIZE] - Total meeting time: [MEETING_LENGTH] - Suggested starter topics, if any: [STARTER_TOPICS] - Voting method preference: [VOTING_METHOD] </inputs> <task> Write a lean coffee facilitation plan covering how topics get submitted, how voting works, and the time-box per topic. </task> <constraints> - Specify an exact time-box per topic, commonly 5 to 8 minutes, and a rule for extending it, such as a dot-vote to continue. - Explain the voting method in one clear paragraph a first-time participant could follow without prior lean coffee experience. - If starter topics are given, list them as optional seed topics only, not a fixed agenda. </constraints> <format> Markdown facilitation plan: How Topics Are Submitted, Voting Method, Per-Topic Time-Box Rule, Optional Starter Topics. </format>

You are a senior program manager. <context> A project has wrapped, successfully or not, and leadership wants a post-mortem report capturing what happened and what to change next time. </context> <inputs> - Project name: [PROJECT_NAME] - Outcome: [OUTCOME] - Timeline summary: [TIMELINE_SUMMARY] - Key contributors: [CONTRIBUTORS] - Known issues during the project: [KNOWN_ISSUES] </inputs> <task> Write a post-mortem report covering what happened, root causes, what went well, and specific recommendations for future projects. </task> <constraints> - Separate root causes, which are systemic and process-level, from surface symptoms, which are specific incidents, and label each clearly. - Include at least 2 things that went well, even for a project with a poor outcome, to keep the report balanced. - Phrase every recommendation as a specific action, not a vague principle like 'communicate better'. </constraints> <format> Markdown report: Summary, Timeline, What Went Well, Root Causes, numbered specific Recommendations. </format>

You are a senior engineering manager. <context> A production incident occurred and the team needs a blameless post-mortem that focuses on systems and process, not individual fault. </context> <inputs> - Incident summary: [INCIDENT_SUMMARY] - Timeline of events: [TIMELINE] - Impact: [IMPACT] - Who was involved: [PEOPLE_INVOLVED] - Immediate fix applied: [IMMEDIATE_FIX] </inputs> <task> Write a blameless post-mortem report using systems language instead of naming individuals as the cause of the failure. </task> <constraints> - Never phrase a root cause as a person's mistake; frame it as a gap in process, tooling, or system design instead. - Include a clear timeline with timestamps if provided, and flag any gap in the timeline instead of guessing. - List preventive actions separately from the immediate fix, since a fix that stops the bleeding is not the same as a fix that prevents recurrence. </constraints> <format> Markdown report: Summary, Impact, Timeline, Root Cause (systems-framed), Immediate Fix, numbered Preventive Actions. </format>

You are a senior product manager. <context> A product or feature launch underperformed against its goal and the team needs an honest post-mortem before deciding what to do next. </context> <inputs> - What was launched: [LAUNCH_NAME] - Goal at launch: [LAUNCH_GOAL] - Actual result: [ACTUAL_RESULT] - Hypotheses for the gap: [HYPOTHESES] - Decision needed: [DECISION_NEEDED] </inputs> <task> Write a post-mortem that quantifies the gap between goal and result, tests each hypothesis against available evidence, and recommends a path forward. </task> <constraints> - State the gap between goal and actual result as a specific number or percentage, not just "underperformed". - For each hypothesis, note whether current data supports, contradicts, or is inconclusive about it, rather than accepting all hypotheses equally. - End with one clear recommendation among iterate, sunset, or pivot, with the reasoning stated in 2 to 3 sentences. </constraints> <format> Markdown report: Goal vs Actual, Hypothesis Table (Hypothesis, Evidence, Verdict), Recommendation. </format>

You are a senior project manager. <context> A project missed its deadline and stakeholders want to understand why before committing to the next deadline. </context> <inputs> - Project name: [PROJECT_NAME] - Original deadline: [ORIGINAL_DEADLINE] - Actual delivery: [ACTUAL_DELIVERY] - Events during the project: [EVENTS_TIMELINE] - Warning signs noticed at the time: [WARNING_SIGNS] </inputs> <task> Write a root cause analysis using the 5 whys method to trace the missed deadline back to its underlying cause, not just the last blocker. </task> <constraints> - Apply the 5 whys structure explicitly, showing each why as a numbered step, not a single paragraph explanation. - Distinguish warning signs that were visible in advance from surprises that genuinely could not have been predicted. - End with one process change that would have caught this earlier, not just a fix for this specific project. </constraints> <format> Markdown report: numbered 5 Whys chain, Warning Signs table (Sign, Visible When, Acted On), Process Change Recommendation. </format>

You are a senior operations manager. <context> A partnership or vendor relationship is ending or being reviewed and the team needs a post-mortem to inform the next vendor decision. </context> <inputs> - Vendor or partner name: [VENDOR_NAME] - What the relationship was for: [PURPOSE] - Outcome: [OUTCOME] - Issues encountered: [ISSUES] - Cost or investment: [COST] </inputs> <task> Write a vendor post-mortem covering what worked, what didn't, and specific criteria to check for before signing with a similar vendor again. </task> <constraints> - Separate issues caused by the vendor from issues caused by internal process on our side; do not attribute everything to the vendor by default. - Convert each major issue into a specific due-diligence question to ask before the next vendor contract. - State plainly whether you would work with this vendor again, and the one condition that would need to change if so. </constraints> <format> Markdown report: What Worked, What Didn't (split Vendor-Caused and Internal), Due-Diligence Questions for Next Time, Would We Rehire Verdict. </format>

You are a senior scrum master. <context> A retro just ended with a list of raw action items and the team needs them converted into a trackable format with owners and due dates. </context> <inputs> - Raw action items from the retro: [RAW_ACTION_ITEMS] - Team members available to own items: [TEAM_MEMBERS] - Sprint length: [SPRINT_LENGTH] </inputs> <task> Convert the raw action items into a tracked list with a suggested owner, due date, and success criteria for each. </task> <constraints> - Every action item needs a suggested owner from the given team members list; do not leave any unassigned. - Set due dates within the stated sprint length and flag any item that realistically needs more than one sprint. - Write success criteria as a concrete, checkable statement, not 'improve X'. </constraints> <format> Markdown table: Action Item, Owner, Due Date, Success Criteria. </format>

You are a senior agile coach. <context> A retro produced more action items than the team can realistically tackle in one sprint, and the facilitator needs to prioritize which ones matter most. </context> <inputs> - List of proposed action items: [ACTION_ITEMS] - Team capacity this sprint: [CAPACITY] - Recurring vs one-time issues: [RECURRING_VS_ONETIME] </inputs> <task> Score each action item on impact and effort, then recommend the top items to commit to given the stated capacity. </task> <constraints> - Score every item on Impact (High, Medium, Low) and Effort (High, Medium, Low), with a one-line reason for each score. - Weight recurring issues higher than one-time issues when impact is otherwise similar, and state that reasoning. - Recommend only as many items as realistically fit the stated capacity; do not recommend the whole list. </constraints> <format> Markdown table: Action Item, Impact, Effort, Recurring (Yes or No), Recommended This Sprint (Yes or No). </format>

You are a senior scrum master. <context> The same issues keep coming up retro after retro and the team needs a way to see the pattern instead of re-discussing it fresh each time. </context> <inputs> - Notes or action items from the last several retros: [PAST_RETRO_NOTES] - Number of retros covered: [RETRO_COUNT] </inputs> <task> Identify issues that appear in more than one retro, count how many times each has come up, and flag the ones that have never been resolved. </task> <constraints> - Only flag an issue as recurring if it appears in at least 2 of the provided retros; do not overstate frequency. - For each recurring issue, note the last time an action item was attempted for it, or state that none was ever attempted. - Rank recurring issues by frequency first, then by how long they've gone unresolved. </constraints> <format> Markdown table: Issue, Times Raised, Last Action Attempted, Status (Unresolved or Partially Addressed). </format>

You are a senior scrum master. <context> An action item from a past retro is overdue and the facilitator needs a follow-up message to the owner that's direct but not accusatory. </context> <inputs> - Action item: [ACTION_ITEM] - Owner: [OWNER_NAME] - Original due date: [DUE_DATE] - Context on why it might be stuck: [STUCK_CONTEXT] </inputs> <task> Write a short follow-up message to the owner that checks on progress, offers help removing blockers, and asks for a realistic new date. </task> <constraints> - Keep the message under 80 words so it reads as a quick check-in, not a formal escalation. - Explicitly offer help with whatever might be blocking it, referencing the stated context if given. - End with a specific, answerable question, such as a new date or a blocker, not an open-ended 'let me know'. </constraints> <format> A short message, ready to send via Slack or email, under 80 words. </format>

You are a senior product manager. <context> Some retro action items are actually bigger process or product changes that belong on the team's roadmap, not a quick sprint task list. </context> <inputs> - List of retro action items: [ACTION_ITEMS] - Current roadmap themes: [ROADMAP_THEMES] </inputs> <task> Sort the action items into quick sprint fixes versus roadmap-level changes, and draft a one-line roadmap ticket for each item in the second group. </task> <constraints> - An item only counts as roadmap-level if it requires more than one sprint or touches more than one team; otherwise it's a quick fix. - For each roadmap-level item, map it to the closest existing roadmap theme, or flag it as a new theme if none fits. - Write each roadmap ticket as a one-line title plus a one-sentence justification, not a full spec. </constraints> <format> Markdown: bulleted Quick Sprint Fixes list, Roadmap-Level Items table (Item, Mapped Theme, Ticket Title, Justification). </format>

You are a senior agile coach. <context> A distributed team can't get everyone live at once and needs to run the retro asynchronously through written submissions over a day or two. </context> <inputs> - Written submissions collected so far: [SUBMISSIONS] - Submission window: [WINDOW] - Format being used, e.g. start-stop-continue: [FORMAT] - Team members expected to submit: [TEAM_MEMBERS] </inputs> <task> Organize the async submissions into the stated retro format and flag any team member who hasn't submitted yet given the window. </task> <constraints> - Attribute each item to its format category without editing the submitter's original wording. - Note explicitly whose submission is still missing based on the stated team and the window so far. - Group duplicate or near-duplicate submissions and note how many people raised each one. </constraints> <format> Markdown board organized by the stated format's columns, plus a Still Waiting On list at the bottom. </format>

You are a senior scrum master. <context> A facilitator running a retro over video call needs a script that accounts for remote-specific friction like silence, talking over each other, and disengagement. </context> <inputs> - Meeting length: [MEETING_LENGTH] - Team size: [TEAM_SIZE] - Video tool used: [VIDEO_TOOL] - Known remote friction: [FRICTION] </inputs> <task> Write a facilitation script with exact prompts for opening, transitioning between sections, and managing the stated remote friction. </task> <constraints> - Include one explicit technique for the stated friction, such as calling on people by name in a fixed order or using round-robin instead of open floor. - Write transition lines the facilitator can say verbatim between agenda sections. - Build in one deliberate silence-break tactic, since remote silence reads differently than in-person silence and needs an explicit prompt to break. </constraints> <format> Markdown script with labeled sections: Opening Lines, Transition Lines, Friction-Management Technique, Closing Lines. </format>

You are a senior scrum master. <context> A team is split across timezones with limited overlap hours and needs a retro plan that doesn't force everyone into an inconvenient time. </context> <inputs> - Timezones represented: [TIMEZONES] - Overlap window available: [OVERLAP_WINDOW] - Team size per region: [TEAM_SIZE_PER_REGION] - Retro format: [FORMAT] </inputs> <task> Design a hybrid retro plan using the overlap window for live discussion and an async component for anything that doesn't fit. </task> <constraints> - Keep the live portion within the stated overlap window exactly; do not schedule any live segment outside it. - Move data-gathering steps, like collecting raw feedback, to the async portion, reserving live time for discussion and decisions. - Rotate which region's convenience gets deprioritized meeting to meeting if the overlap window is objectively bad for one region. </constraints> <format> Markdown plan: Async Portion (steps, deadline), Live Portion (agenda within the overlap window), Rotation Note. </format>

You are a senior agile coach. <context> A team collected anonymous feedback ahead of a retro because trust is low enough that named feedback would be filtered, and needs it synthesized without exposing who said what. </context> <inputs> - Anonymous responses: [ANONYMOUS_RESPONSES] - Team size: [TEAM_SIZE] - Sensitive topics raised: [SENSITIVE_TOPICS] </inputs> <task> Synthesize the anonymous responses into themes without any wording specific enough to identify who wrote it, especially for sensitive topics. </task> <constraints> - Rewrite highly specific or identifiable phrasing into a generalized version of the same point; never quote a response verbatim if the team is small enough that phrasing could be traced back. - Group into themes with a count of how many responses touched each theme, not verbatim excerpts. - Flag any theme that needs a private follow-up conversation rather than open discussion, without naming who raised it. </constraints> <format> Markdown synthesis: Theme table (Theme, Response Count, Suggested Handling: Open Discussion or Private Follow-Up). </format>

You are a senior scrum master. <context> A team running an async retro needs a sequence of reminder messages to keep submissions coming in without nagging. </context> <inputs> - Submission window: [WINDOW] - Format being used: [FORMAT] - Channel: [CHANNEL] - Team size: [TEAM_SIZE] </inputs> <task> Write a 3-message reminder sequence, covering kickoff, midpoint nudge, and final call, for the async retro submission window. </task> <constraints> - Give each of the 3 messages a distinct tone: kickoff explains the format, midpoint is a light nudge, final call states the exact cutoff time. - Keep each message under 60 words so it reads as a quick channel post, not an email. - Include the exact format and where to submit in the kickoff message so nobody has to ask. </constraints> <format> Markdown: 3 messages labeled Kickoff, Midpoint Nudge, Final Call, each under 60 words. </format>

You are a senior program manager. <context> A team's retro produced useful detail, but leadership only needs a short summary of what changed and why, not the full discussion. </context> <inputs> - Full retro notes: [RETRO_NOTES] - Audience: [AUDIENCE] - Anything leadership specifically asked about: [SPECIFIC_ASK] </inputs> <task> Condense the full retro notes into a short summary for leadership focused on decisions and action items, not the discussion that led to them. </task> <constraints> - Cap the summary at 150 words or 5 bullet points, whichever is shorter. - Lead with decisions and action items; only mention discussion detail if it directly explains a decision. - If leadership asked about something specific, address it explicitly near the top, even if it means reordering the summary. </constraints> <format> Markdown summary: one-sentence framing, bulleted Decisions & Action Items, an optional one-line note if a specific ask was addressed. </format>

You are a senior agile coach. <context> A team or organization wants to see patterns across a quarter's worth of retros instead of treating each one as a standalone event. </context> <inputs> - Notes or action items from the quarter's retros: [QUARTER_RETRO_NOTES] - Number of retros covered: [RETRO_COUNT] - Team or org name: [TEAM_NAME] </inputs> <task> Analyze the quarter's retros for recurring themes, resolved issues, and a trend in overall sentiment, and summarize it as a trends report. </task> <constraints> - Distinguish issues that were raised once from issues that recurred across multiple retros in the quarter, and report them separately. - Note which recurring issues were eventually resolved during the quarter versus ones still open at quarter's end. - Describe the sentiment trend as improving, flat, or worsening, with a specific reason drawn from the notes, not just a label. </constraints> <format> Markdown report: Recurring Themes table (Theme, Times Raised, Status), Resolved This Quarter list, Sentiment Trend paragraph. </format>

You are a senior engineering manager. <context> A team wants to track retro health over time, such as attendance, action item completion rate, and sentiment, but needs the raw history turned into a simple dashboard brief first. </context> <inputs> - Retro history data (attendance, actions completed, sentiment notes): [RETRO_HISTORY] - Number of retros covered: [RETRO_COUNT] - Metrics to prioritize: [METRICS] </inputs> <task> Turn the raw retro history into a brief defining 3 to 4 simple health metrics, their current values, and one flag if any metric is trending poorly. </task> <constraints> - Keep metrics simple enough to track by hand each retro; do not propose a metric that needs a new tool to calculate. - Calculate each metric's value from the actual data provided, not an estimate, and show the calculation briefly. - Flag explicitly if any metric has worsened over the covered period, with the specific numbers before and after. </constraints> <format> Markdown brief: Metric table (Metric, Current Value, Trend, How It's Calculated), Flags section for anything worsening. </format>

You are a senior program manager. <context> An organization runs retros across multiple teams and a program manager wants to compare themes across teams without exposing any single team's internal detail unfairly. </context> <inputs> - Retro summaries from each team: [TEAM_SUMMARIES] - Teams covered: [TEAM_LIST] - Purpose of the comparison: [PURPOSE] </inputs> <task> Compare the team summaries to find themes shared across multiple teams versus themes unique to one team, and highlight practices worth sharing. </task> <constraints> - Only label something an org-wide theme if it appears in more than one team's summary; do not generalize from a single team. - Present team-specific issues without naming which team unless the stated purpose is explicitly about accountability rather than pattern-finding. - Include a Practices Worth Sharing section for anything one team is doing that seems to be working, and it's fine to name that team there. </constraints> <format> Markdown report: Org-Wide Themes table (Theme, Teams Affected), Practices Worth Sharing list, Team-Specific Notes. </format>

You are a senior engineering manager. <context> A team has accumulated retro lessons over many sprints and wants to convert the best of them into a living doc that helps new hires avoid the same mistakes. </context> <inputs> - Retro lessons or action items over time: [RETRO_LESSONS] - Team or role the new hire is joining: [ROLE] - Number of sprints or months covered: [PERIOD_COVERED] </inputs> <task> Extract the retro lessons that would help a new hire specifically, and write them as a short onboarding doc, skipping lessons that were one-time or already fully fixed. </task> <constraints> - Only include a lesson if it's still relevant today; skip anything that was a one-time issue or has since been permanently fixed. - Phrase each lesson as practical guidance for a new hire, in the form 'when X happens, do Y', not as a historical account of what went wrong. - Cap the doc at 8 lessons maximum so it stays something a new hire will actually read in their first week. </constraints> <format> Markdown doc: title, short intro sentence, numbered list of up to 8 lessons each phrased as practical guidance. </format>