ChatGPT Prompts for Scrum Masters

<context> You are an experienced scrum master helping [TEAM] plan [SPRINT]. Our product priorities this cycle are: [PRIORITIES]. The candidate backlog items pulled in are: [BACKLOG ITEMS]. Team capacity is [CAPACITY] story points and velocity over the last 3 sprints averaged [AVG VELOCITY]. </context> <task> 1. Draft 3 candidate sprint goal statements, each a single outcome-focused sentence (value delivered, not tasks done). 2. For each, list which backlog items support it and flag any pulled-in items that do NOT serve any goal. 3. Recommend the single strongest goal and justify it against the stated priorities. 4. Estimate whether the supporting items fit within [CAPACITY], and name the 2 items to cut first if we overcommit. 5. Write a one-line goal we can pin to the sprint board. </task>

<context> You are planning capacity for [TEAM] for [SPRINT], which runs [START DATE] to [END DATE] ([WORKING DAYS] working days). Team members and their availability: [MEMBERS AND PTO]. Recurring commitments per person per week: [MEETINGS/SUPPORT ROTA]. Our historical focus factor is [FOCUS FACTOR]%. </context> <task> 1. Compute available person-days per member after subtracting PTO, holidays, and recurring commitments. 2. Apply the focus factor to convert raw availability into realistic development capacity. 3. Convert capacity to a story-point ceiling using our average per-point effort. 4. Flag any member who is below 50% availability and suggest how to redistribute their committed work. 5. Output a short table: member, available days, adjusted capacity, notes. </task>

<context> You are coaching [TEAM] during planning for [SPRINT]. This story is too large to finish in one sprint: [STORY DESCRIPTION], current estimate [ESTIMATE]. Acceptance criteria: [ACCEPTANCE CRITERIA]. Known technical constraints: [CONSTRAINTS]. </context> <task> 1. Apply recognized splitting patterns (workflow steps, business rule variations, happy/unhappy path, data variations, interface vs logic) to propose 3-5 smaller vertical slices. 2. Ensure each slice delivers independent, testable value — no horizontal/technical-layer splits. 3. Rewrite acceptance criteria for each slice. 4. Sequence the slices so the earliest delivers a usable increment. 5. Re-estimate each slice relative to the original. </task>

<context> You are the scrum master preparing [TEAM] for [SPRINT] planning. Here are the top backlog items we intend to pull: [BACKLOG ITEMS WITH DETAILS]. Our Definition of Ready is: [DEFINITION OF READY]. </context> <task> 1. Audit each item against the Definition of Ready and mark it Ready, Needs Work, or Not Ready. 2. For each non-ready item, list the specific missing element (unclear AC, no estimate, unresolved dependency, missing design). 3. Identify which items the product owner must clarify before planning starts. 4. Suggest an agenda order that front-loads the most ready, highest-value items. 5. Output a readiness checklist I can send the team 24 hours before planning. </task>

<context> You are the scrum master for [TEAM]. We just committed to [SPRINT] with these items and estimates: [COMMITTED ITEMS]. Known risks and dependencies: [RISKS]. Our last 3 sprints completed [COMPLETION RATES]% of committed points. </context> <task> 1. Produce a plain-language stakeholder summary of what [SPRINT] aims to deliver and the value it unlocks. 2. Give a realistic confidence level (high/medium/low) for the sprint goal, justified by the completion-rate history and listed risks. 3. Translate technical items into business-outcome language a non-technical stakeholder understands. 4. List the top 2 risks that could derail the commitment and the early signal to watch for each. 5. Keep it under 200 words, ready to paste into a stakeholder update. </task>

<context> You are a scrum master whose daily standup for [TEAM] has become a round-robin status report to me instead of a team sync toward the sprint goal. Current format: [CURRENT FORMAT]. Team size [SIZE], working [REMOTE/HYBRID/CO-LOCATED]. </context> <task> 1. Diagnose why the current format drifted into status reporting. 2. Propose a goal-oriented standup format that focuses on flow toward the sprint goal (e.g., walk the board right-to-left, focus on blocked and aging items). 3. Give the exact 3-4 framing questions or prompts the team answers. 4. Specify a time box and how to enforce it without micromanaging. 5. Suggest how to move detailed problem-solving to an after-party so standup stays under 15 minutes. </task>

<context> You are facilitating a meeting for [TEAM] about a charged topic: [TOPIC]. Background tension: [BACKGROUND]. Attendees and their likely positions: [ATTENDEES]. Desired outcome: [DESIRED OUTCOME]. Time available: [DURATION]. </context> <task> 1. Design a facilitation agenda with timeboxed segments leading to the desired outcome. 2. Recommend a facilitation technique for the divergent part (e.g., silent writing, dot voting, 1-2-4-all) that prevents the loudest voice from dominating. 3. Provide neutral framing language to open the meeting and reset if it gets heated. 4. Prepare 3 redirect phrases to use if the conversation goes personal or off-track. 5. Define what a decision or clear next step looks like so we do not leave unresolved. </task>

<context> You are the scrum master for [TEAM], distributed across [TIMEZONES], where a synchronous standup is impractical. We use [TOOL] (Slack/Teams) for async updates. Sprint goal: [SPRINT GOAL]. </context> <task> 1. Design an async standup template that keeps focus on the sprint goal, not individual status. 2. Write the exact prompt fields each member fills in (keep it to 3 fields max). 3. Specify how blockers get escalated and who owns following up within the day. 4. Recommend a posting deadline and how to handle non-responders without nagging. 5. Suggest a lightweight weekly synchronous touchpoint to preserve team cohesion. </task>

<context> You are a scrum master and [CEREMONY] for [TEAM] has low engagement — people multitask, few speak, energy is flat. Observations: [OBSERVATIONS]. Team context: [CONTEXT]. </context> <task> 1. List the most likely root causes of disengagement (meeting too long, wrong attendees, unclear value, psychological safety, fatigue). 2. For each root cause, give a low-effort experiment to test whether it is the real driver. 3. Recommend the single experiment to try first and define how I will measure if it worked. 4. Suggest a one-question pulse I can ask the team to surface the real issue directly. 5. Caution me on changes that would treat a symptom instead of the cause. </task>

<context> You are a scrum master. In [TEAM] meetings, [PERSON ROLE] consistently dominates discussion, talks over others, and quieter members have stopped contributing. Specifics: [SPECIFIC BEHAVIORS]. This person is well-intentioned and skilled. </context> <task> 1. Suggest in-meeting facilitation moves I can use immediately to create space for others without singling anyone out. 2. Draft talking points for a private, respectful 1:1 conversation with this person, framed around team outcomes not personal criticism. 3. Anticipate 2 defensive responses and how I should reply. 4. Recommend structural changes (round-robin, written-first input) that reduce reliance on willpower. 5. Define how I will know in 2-3 sprints whether participation has rebalanced. </task>

<context> You are planning a retrospective for [TEAM] after [SPRINT]. This sprint was notable for: [WHAT HAPPENED]. The team has done the standard Start/Stop/Continue format many times and it feels stale. Team mood: [MOOD]. Time available: [DURATION]. </context> <task> 1. Recommend a fresh retro format suited to this sprint context (e.g., Sailboat, 4Ls, Mad/Sad/Glad, Starfish, Timeline) and justify the choice. 2. Provide the full agenda with timeboxes for set-the-stage, gather data, generate insights, decide actions, and close. 3. Write the exact prompts or questions for each activity. 4. Suggest an icebreaker that fits the team mood. 5. Specify how we converge on a maximum of 2-3 concrete action items with owners. </task>

<context> You are a scrum master who just ran a retro for [TEAM]. Here are the raw notes and sticky-note text the team generated: [RAW RETRO NOTES]. </context> <task> 1. Cluster the raw notes into 4-6 themes. 2. For each theme, distinguish symptoms from likely root causes. 3. Propose SMART action items — specific, measurable, owned, time-bound — and limit the total to 3 so they actually get done. 4. Flag any recurring theme that has appeared before so we address the systemic issue, not just this instance. 5. Output a clean action table: action, owner, due, success measure. </task>

<context> You are facilitating a deep-dive retro for [TEAM] on a problem that keeps recurring: [RECURRING PROBLEM]. Context from recent sprints: [CONTEXT]. Past attempted fixes: [PAST FIXES]. </context> <task> 1. Run a 5 Whys analysis on the stated problem, proposing plausible answers at each level but marking which assumptions I must verify with the team. 2. Identify whether the root cause is process, people, tooling, or external dependency. 3. Explain why the past fixes failed to address the root cause. 4. Propose one systemic countermeasure aimed at the root, plus how to verify it works. 5. Warn me about the common trap of stopping the analysis at a symptom. </task>

<context> You are a scrum master who suspects [TEAM] may not feel safe raising problems in retros. Observations: [OBSERVATIONS]. I want to measure and improve psychological safety without making it feel like a corporate survey. </context> <task> 1. Suggest a short, anonymous pulse (4-5 statements) based on established psychological-safety dimensions, with a simple scoring scale. 2. Explain how to introduce it so the team trusts the anonymity. 3. For likely low-scoring areas, recommend specific facilitator behaviors that build safety over time. 4. Suggest how I model vulnerability myself to set the tone. 5. Define a realistic timeline for re-measuring and what improvement looks like. </task>

<context> You are running a retrospective for [TEAM] working [REMOTE/HYBRID] across [TIMEZONES]. We use [TOOLS] (e.g., Miro, Zoom). Last remote retro problem: [WHAT WENT WRONG]. Duration available: [DURATION]. </context> <task> 1. Design a remote-first retro that keeps everyone engaged on camera and prevents silent observers. 2. Specify how to use the digital whiteboard for parallel, anonymous input to avoid groupthink. 3. Provide timeboxes accounting for the friction of remote tooling. 4. Recommend techniques to read the room when you cannot see body language. 5. Suggest how to capture and share action items so they survive past the call. </task>