30 Claude Prompts for Scrum Masters

You are a scrum master who keeps a shared impediment log that engineering leadership actually reads. <context> A blocker came up in standup today and I need to log it properly so it does not get lost or repeated next sprint. </context> <inputs> - Blocker description: [BLOCKER DESCRIPTION] - Who raised it: [PERSON NAME] - Date raised: [DATE] - Impact on sprint goal: [IMPACT DESCRIPTION] - Suggested owner for resolution: [SUGGESTED OWNER] </inputs> <task> Write a clear impediment log entry with a severity rating, the sprint impact, a suggested next step, and a follow up date. </task> <constraints> Keep the entry to five lines or fewer. Use a severity scale of Low, Medium, High, Critical and justify the rating in one clause. Do not assign blame to any individual, describe the system or process issue instead. </constraints> <format> Return the entry as a single row with fields: Date, Description, Severity, Impact, Owner, Follow up date. </format>

You are a scrum master who needs to escalate a blocker past the team level to get it resolved. <context> A blocker has sat unresolved for several days and is now threatening the sprint goal, so I need to escalate it to a manager without sounding like I am complaining. </context> <inputs> - Blocker: [BLOCKER DESCRIPTION] - Days blocked: [NUMBER OF DAYS] - Who it affects: [AFFECTED PEOPLE OR TEAMS] - Manager or team to escalate to: [RECIPIENT NAME OR TEAM] - What I need from them: [SPECIFIC ASK] </inputs> <task> Draft a short escalation email that states the business impact plainly, gives the timeline of attempted fixes, and ends with one specific ask. </task> <constraints> Keep the email under 150 words. Tone should be direct and factual, not apologetic or accusatory. End with exactly one clear ask, not a list of options. </constraints> <format> Return a subject line and email body, plain text, no headers or footers beyond a one line sign off. </format>

You are a scrum master responsible for maintaining the team's risk register alongside the impediment log. <context> I want to update our risk register before the next planning session so leadership can see what could threaten the roadmap, not just what already went wrong. </context> <inputs> - Current known risks: [LIST OF RISKS] - New risk identified this sprint: [NEW RISK DESCRIPTION] - Likelihood estimate: [LIKELIHOOD] (low, medium, high) - Potential impact if it happens: [IMPACT DESCRIPTION] - Mitigation ideas so far: [MITIGATION IDEAS] </inputs> <task> Update the risk register by rewriting existing entries for clarity and adding the new risk with likelihood, impact, and a mitigation owner. </task> <constraints> Use a consistent likelihood and impact scale of Low, Medium, High across all rows. Keep each risk description to one sentence. Flag any risk that is both High likelihood and High impact at the top. </constraints> <format> Return a table with columns Risk, Likelihood, Impact, Mitigation, Owner, sorted with the highest combined risk first. </format>

You are a scrum master coordinating work that depends on two other teams outside your own. <context> Our sprint has three items blocked on external teams and I need a clear report on where each dependency stands before our sync meeting. </context> <inputs> - Dependent items: [LIST OF DEPENDENT ITEMS] - External teams involved: [TEAM NAMES] - Last known status of each: [STATUS NOTES] - Deadline pressure: [DEADLINE DETAILS] </inputs> <task> Write a dependency tracking report that shows each item, the external team it depends on, current status, and the risk to our sprint deadline if it slips. </task> <constraints> Be specific about which team owns the next action for each dependency. Flag anything with no clear next action as At risk. Keep the report to one page. </constraints> <format> Return a table with columns Item, Depends on, Status, Next action, Owner, Risk level. </format>

You are a scrum master analyzing several sprints of impediment log data to find recurring root causes. <context> I have logged impediments for the last several sprints and I suspect the same root cause keeps resurfacing in different disguises, I want that pattern named clearly. </context> <inputs> - Impediment log entries across sprints: [PASTE LOG ENTRIES OR SUMMARY] - Number of sprints covered: [NUMBER OF SPRINTS] - Team's own guess at the pattern: [TEAM HYPOTHESIS OR NONE] </inputs> <task> Analyze the impediment entries for recurring themes, name the two or three most likely root causes, and propose one structural fix for each. </task> <constraints> Distinguish between symptoms and root causes explicitly. Do not propose more than one fix per root cause. If the data does not support a clear pattern, say so plainly instead of forcing a conclusion. </constraints> <format> Return a short summary paragraph, then a table with columns Root cause, Evidence, Frequency, Proposed fix. </format>

You are a scrum master who runs a quarterly team health check survey and needs to turn raw responses into an honest summary. <context> I collected anonymous survey responses on team health this quarter and I need to summarize the results for the team without exposing who said what. </context> <inputs> - Survey categories: [CATEGORIES] (workload, clarity, trust, tooling) - Raw scores or comments: [PASTE SCORES OR COMMENTS] - Previous quarter scores for comparison: [PREVIOUS SCORES] - Team size: [NUMBER OF RESPONDENTS] </inputs> <task> Summarize the survey results into a short report that highlights what improved, what declined, and one theme worth discussing openly with the team. </task> <constraints> Never quote a comment in a way that could identify who wrote it. Compare against the previous quarter numerically where data exists. Pick exactly one theme to bring to the team, not a long list. </constraints> <format> Return a short paragraph summary, then a table with columns Category, This quarter, Last quarter, Trend, followed by one sentence naming the discussion theme. </format>

You are a scrum master preparing a velocity report for a planning session, aware that velocity is easy to misread. <context> Leadership keeps asking about velocity trends and I want a report that shows the real pattern without encouraging anyone to treat velocity as a productivity score. </context> <inputs> - Velocity by sprint: [LIST OF SPRINT NUMBERS AND POINTS] - Team size changes during this period: [TEAM CHANGES OR NONE] - Notable disruptions: [DISRUPTIONS] (holidays, incidents) </inputs> <task> Write a velocity trend report that shows the numbers plainly, explains any dips or spikes using the context given, and adds a caution against using velocity to compare across teams. </task> <constraints> Do not suggest velocity should be increased as a goal in itself. Explicitly connect any dip to a stated cause where one exists. Keep the caution note to two sentences. </constraints> <format> Return a table with columns Sprint, Velocity, Notable factor, followed by a short paragraph interpretation and a two sentence caution note. </format>

You are a scrum master explaining a sprint burndown chart to stakeholders who are not familiar with reading one. <context> Our burndown chart flattened for three days mid sprint and I need to explain what happened in plain terms during the sprint review. </context> <inputs> - Burndown pattern description: [DESCRIBE THE SHAPE] (flat days 4 to 6, then a steep drop) - Cause of the flat period: [CAUSE] - Final outcome: [FINAL OUTCOME] (finished on time, finished late) - Audience: [AUDIENCE] (product stakeholders) </inputs> <task> Write a plain language narrative that explains what the burndown chart shape means, why it flattened, and what it does or does not indicate about team performance. </task> <constraints> Avoid technical scrum jargon the audience may not know. Do not let the narrative imply the team was idle during the flat period if that is not true. Keep it to one short paragraph. </constraints> <format> Return a single paragraph of 4 to 6 sentences, written as if read aloud during the sprint review. </format>

You are a scrum master reading weekly one word mood check ins the team submits after standup. <context> Each week I collect a one word mood and a short optional comment from the team, and this week the words trended more negative than usual. </context> <inputs> - This week's mood words: [LIST OF MOOD WORDS] - Optional comments: [OPTIONAL COMMENTS] - Last four weeks trend: [PREVIOUS WEEKS SUMMARY] - Known context this week: [CONTEXT] (release week, reorg rumor) </inputs> <task> Analyze the mood pulse for this week against the recent trend, connect it to known context where plausible, and recommend one action, which may be to simply check in privately with someone or to raise a topic at retro. </task> <constraints> Do not overreact to a single low week if the trend before it was stable. Name any single person's comment only if they gave clear permission to share it, otherwise speak in aggregate. Recommend exactly one action. </constraints> <format> Return a short paragraph interpretation followed by one line labeled Recommended action. </format>

You are a scrum master building a capacity plan ahead of a sprint that has unusual time off and onboarding overlap. <context> This sprint has two people out for part of the week and a new hire ramping up, and I want to calculate realistic capacity instead of assuming full availability. </context> <inputs> - Team members and standard capacity: [LIST OF NAMES AND HOURS OR POINTS] - Planned time off: [TIME OFF DETAILS] - New hire ramp estimate: [RAMP PERCENTAGE] (50 percent productive) - Sprint length: [SPRINT LENGTH] </inputs> <task> Calculate an adjusted team capacity for the sprint that accounts for time off and the new hire's reduced ramp, and show the math so it can be checked. </task> <constraints> Show the calculation per person, not just a final total. Round conservatively rather than optimistically when the ramp percentage is uncertain. Note any assumption made explicitly. </constraints> <format> Return a table with columns Person, Standard capacity, Adjustment, Adjusted capacity, then a final line with Total adjusted capacity and any assumptions listed below it. </format>

You are a scrum master preparing for a one on one with a team member you coach but do not manage. <context> I have a one on one coming up with a developer on my team and I want to prepare questions that go beyond status updates into how they are actually growing. </context> <inputs> - Team member name and role: [NAME AND ROLE] - Recent context: [RECENT CONTEXT] (just finished a hard project) - Growth area they mentioned before: [GROWTH AREA] - Time available: [MINUTES] </inputs> <task> Prepare a short list of open ended coaching questions for the one on one that connect to their stated growth area and avoid becoming a status check. </task> <constraints> Write questions that cannot be answered with yes or no. Limit the list to five questions so the conversation stays natural rather than feeling like an interview. Do not include any question about ticket status or deadlines. </constraints> <format> Return a numbered list of five questions, each followed in parentheses by the coaching intent behind it. </format>

You are a scrum master who needs to raise a pattern of missed commitments with a team member without damaging trust. <context> A team member has missed their sprint commitments three sprints in a row and I need to raise it directly but with care, since I do not manage them formally. </context> <inputs> - Team member name: [NAME] - Pattern observed: [PATTERN] (estimates consistently missed by half) - Possible causes I suspect: [SUSPECTED CAUSES] - Relationship history: [RELATIONSHIP CONTEXT] (generally strong until recently) </inputs> <task> Draft a conversation opener and a short script outline that names the pattern factually, invites their perspective first, and avoids assuming the cause before hearing them out. </task> <constraints> Open with a question, not an accusation. Do not propose a solution until after their perspective is stated in the script. Keep the tone supportive and specific, never vague or softened to the point of unclear. </constraints> <format> Return the script in three labeled parts: Opener, Listen and clarify, Next steps, each with example phrasing. </format>

You are a scrum master mediating a disagreement between two engineers that is starting to affect the team's tone in meetings. <context> Two engineers on my team disagree strongly about a technical approach and the tension has started showing up in standup and code review comments. </context> <inputs> - Person A's position: [POSITION A] - Person B's position: [POSITION B] - Where the tension is showing up: [WHERE] (code review comments) - Desired outcome: [DESIRED OUTCOME] (a shared decision they both support) </inputs> <task> Draft a mediation conversation structure for a joint meeting with both people that separates the technical disagreement from the interpersonal tension and moves toward a decision they can both stand behind. </task> <constraints> Do not take a side on the technical question, the structure must stay neutral on that point. Include one explicit ground rule to say out loud at the start of the meeting. Keep the structure to four steps. </constraints> <format> Return a four step meeting structure, one ground rule stated as a sentence to say aloud, and one sentence on how to close if they still disagree after the meeting. </format>

You are a scrum master coaching a team member who wants to grow into a tech lead role within the next year. <context> A developer told me they want to grow into a tech lead role and asked for my help building a plan, and I want something concrete rather than generic advice. </context> <inputs> - Current role and strengths: [CURRENT ROLE AND STRENGTHS] - Target role: [TARGET ROLE] - Gaps they and I have both noticed: [GAPS] - Timeframe: [TIMEFRAME] (12 months) </inputs> <task> Build a coaching plan with three concrete milestones between now and the target timeframe, each with a specific action and a way to know it happened. </task> <constraints> Each milestone must have an observable signal of progress, not just an intention. Space the milestones across the timeframe rather than front loading them. Avoid vague actions like network more or build visibility. </constraints> <format> Return a table with columns Milestone, Target date, Specific action, Signal of progress. </format>

You are an experienced scrum master mentoring someone who just took on their first scrum master role on a different team. <context> I am mentoring a new scrum master who is three weeks into their first team and feeling overwhelmed by how many ceremonies and conversations they are responsible for at once. </context> <inputs> - New scrum master's background: [BACKGROUND] (former developer, new to facilitation) - Team they inherited: [TEAM CONTEXT] (established team with existing habits) - Specific struggle they mentioned: [STRUGGLE] (standups run long and nobody stops them) - Time we have for mentoring: [MENTORING SESSION LENGTH] </inputs> <task> Write mentoring talking points that address their specific struggle first, then give them one thing to try in the next sprint rather than a full overhaul of everything at once. </task> <constraints> Limit the advice to one focus area for the next sprint, resist the urge to cover every scrum master skill at once. Frame feedback as options to try, not rules to follow. Keep the guide to under 350 words. </constraints> <format> Return a short section called What I am hearing, then Try this next sprint, then One question to ask yourself, each two to three sentences. </format>

You are a scrum master who sends a short sprint summary email to stakeholders who do not attend the sprint review. <context> Some stakeholders never make it to the sprint review live, so I send a short recap email after every sprint and I want it tight and consistent. </context> <inputs> - Sprint goal: [SPRINT GOAL] - Completed highlights: [COMPLETED HIGHLIGHTS] - Missed items and reason: [MISSED ITEMS AND REASON] - Next sprint focus: [NEXT SPRINT FOCUS] </inputs> <task> Write a sprint summary email that stakeholders can read in under a minute, covering what shipped, what slipped and why, and what is next. </task> <constraints> Keep the email under 120 words. Use plain business language, no scrum jargon like velocity or story points. State any slipped item's reason in one clause, not a paragraph of excuses. </constraints> <format> Return a subject line and email body with three short sections: Shipped, Slipped, Next up. </format>

You are a scrum master compiling a monthly status report for an executive who tracks multiple teams and has very little time. <context> I report monthly to an executive who oversees several teams and only wants signal, not a play by play of every sprint. </context> <inputs> - Team name: [TEAM NAME] - Key deliverable this month: [KEY DELIVERABLE] - Overall status: [STATUS] (on track, at risk, delayed) - Biggest risk right now: [BIGGEST RISK] - Ask of the executive, if any: [ASK OR NONE] </inputs> <task> Write an executive status update that leads with overall status, states the biggest risk plainly, and includes a specific ask only if one exists. </task> <constraints> Lead with the status word in the first sentence, do not bury it. Keep the entire report to five sentences or fewer. If there is no ask, say so rather than manufacturing one. </constraints> <format> Return a single short paragraph of five sentences maximum, no headers or bullet points. </format>

You are a scrum master who needs to tell a stakeholder that a requested change mid sprint will affect the sprint goal. <context> A stakeholder asked for a scope change partway through the sprint and I need to explain the tradeoff clearly instead of just saying no or silently absorbing it. </context> <inputs> - Requested change: [REQUESTED CHANGE] - Stakeholder who asked: [STAKEHOLDER NAME] - Impact on current sprint goal: [IMPACT] - Options available: [OPTIONS] (swap out another item, push to next sprint) </inputs> <task> Write a message to the stakeholder that acknowledges the request, explains the tradeoff in concrete terms, and presents the available options for them to choose from. </task> <constraints> Do not simply refuse the request, present real tradeoffs instead. Avoid sounding defensive about protecting the sprint, frame it as a shared decision. Limit to two clear options, not an open ended list. </constraints> <format> Return a short message with three parts: Acknowledgment, Tradeoff, Options to choose from, each one to two sentences. </format>

You are a scrum master coordinating a release and reporting readiness to stakeholders who are anxious about the launch date. <context> We have a release coming up and stakeholders keep asking if we are on track, so I want one clear update I can reuse rather than answering the same question five different ways. </context> <inputs> - Release name and date: [RELEASE NAME AND DATE] - Remaining work: [REMAINING WORK ITEMS] - Open risks to the date: [OPEN RISKS] - Confidence level: [CONFIDENCE] (high, medium, low) </inputs> <task> Write a release readiness update that states confidence level up front, lists remaining work briefly, and names the specific risks that could move the date. </task> <constraints> State the confidence level as the first word or phrase of the update. List no more than three remaining work items, group the rest as Other minor items if there are more. Name risks specifically, not as a vague mention of some risk. </constraints> <format> Return a short update with labeled lines: Confidence, Remaining work, Risks to the date, Next check in. </format>

You are a scrum master coordinating with another team's scrum master on a shared dependency between the two teams. <context> Our team has work that depends on another team's output and I want to send a short alignment note to their scrum master to confirm timing before we both plan our next sprints. </context> <inputs> - Our dependent item: [OUR ITEM] - What we need from the other team: [WHAT WE NEED] - Our target sprint or date: [TARGET DATE] - Other team's scrum master name: [NAME] </inputs> <task> Draft a short alignment note to the other scrum master that states what we need, by when, and asks them to confirm or flag a conflict before both teams lock their sprint plans. </task> <constraints> Keep the note under 100 words. Ask a direct yes or no confirmation question at the end, not an open ended one. Avoid assuming their team's capacity, ask rather than state it. </constraints> <format> Return a short message with a clear ask in the first sentence and a direct confirmation question as the last sentence. </format>

You are a scrum master who noticed that retrospective action items get agreed on but rarely followed up. <context> Our retros produce good action items but they quietly disappear because nobody tracks them between retros, and I want a simple tracker to fix that. </context> <inputs> - Action items from last three retros: [LIST OF ACTION ITEMS WITH OWNERS] - Which ones were actually completed: [COMPLETED ITEMS] - Which ones stalled and why, if known: [STALLED ITEMS AND REASON] </inputs> <task> Build a tracker that shows the status of each action item across the last three retros and identify the pattern behind why items stall. </task> <constraints> Use a status of Done, In progress, Stalled, Dropped for each item, do not invent additional statuses. State the stall pattern in one sentence backed by the actual items listed. Keep the tracker to one table. </constraints> <format> Return a table with columns Action item, Owner, Retro date, Status, then one sentence below labeled Pattern. </format>

You are a scrum master proposing a small process change to the team as a time boxed experiment rather than a permanent rule. <context> I want to try a process change but I know the team resists anything that feels like a permanent new rule imposed on them, so I want to frame it as a short experiment. </context> <inputs> - Problem the change addresses: [PROBLEM] - Proposed change: [PROPOSED CHANGE] - Experiment length: [EXPERIMENT LENGTH] (two sprints) - How we will know if it worked: [SUCCESS SIGNAL] </inputs> <task> Write a process experiment proposal that frames the change as reversible, states the success signal clearly, and sets a specific date to review the results. </task> <constraints> Use the word experiment rather than change or new rule throughout. State the reversal plan explicitly, meaning what happens if it does not work. Keep the proposal to one short paragraph plus a review date. </constraints> <format> Return a short paragraph proposal followed by a line labeled Review date and a line labeled If it does not work. </format>

You are a scrum master leading a review of the team's definition of done, which has not been revisited in a long time. <context> Our definition of done was written over a year ago and I suspect it no longer matches how the team actually works, so I want to refresh it with the team rather than rewrite it myself. </context> <inputs> - Current definition of done: [CURRENT DEFINITION OF DONE] - Known gaps or complaints: [KNOWN GAPS] - Recent incidents linked to done criteria: [RECENT INCIDENTS OR NONE] </inputs> <task> Review the current definition of done against the known gaps and recent incidents, and propose a revised version with a facilitation plan for getting team agreement rather than imposing it. </task> <constraints> Mark each proposed change as Added, Removed, or Clarified against the original. Tie any added criterion to a specific gap or incident, not a general best practice. Include a short facilitation step for getting team buy in. </constraints> <format> Return a table with columns Criterion, Change type, Reason, followed by a two sentence facilitation plan for the team discussion. </format>

You are a scrum master drafting a working agreement for a newly formed team that has not yet set shared norms. <context> My team just formed from people who worked on different teams before, and small friction is already showing up around meeting norms and communication expectations. </context> <inputs> - Team composition: [TEAM COMPOSITION] (mix of remote and in office) - Friction already observed: [FRICTION OBSERVED] - Topics to cover: [TOPICS] (meeting etiquette, response time, code review turnaround) </inputs> <task> Draft a starting working agreement covering the topics listed, written as a proposal for the team to edit together rather than a finished policy. </task> <constraints> Write each item as a norm the team commits to, not a rule imposed from above, using language like we agree to. Keep each topic to one or two sentences. Include a line inviting the team to change anything in the first draft. </constraints> <format> Return a short document with one section per topic, each starting with We agree to, plus a closing line inviting edits. </format>

You are a scrum master conducting an honest agile maturity assessment of your team ahead of a planning cycle. <context> I want to assess where my team genuinely stands on agile practices, separate from how the team likes to describe itself, so I can pick one or two real improvement areas. </context> <inputs> - Practices currently in place: [PRACTICES IN PLACE] - Practices attempted but abandoned: [ABANDONED PRACTICES] - Team's self perception: [SELF PERCEPTION] (team thinks it is highly agile) - Area I suspect is weakest: [SUSPECTED WEAK AREA] </inputs> <task> Assess the team's actual agile maturity against the practices listed, note any gap between self perception and reality, and recommend the single highest impact area to improve next. </task> <constraints> Base the assessment only on the practices and evidence given, do not assume maturity from team size or tenure. State the perception gap plainly if one exists, do not soften it into vague language. Recommend exactly one improvement area, not several. </constraints> <format> Return a short paragraph assessment, a line labeled Perception gap, and a line labeled Recommended focus area. </format>