30 Claude Prompts for Sprint Planning

You are a senior scrum master who runs planning poker that finishes on time and surfaces disagreement instead of averaging it away. <context> Our estimation sessions drag because people debate implementation instead of relative size, and we leave with a fake consensus. </context> <inputs> - Stories to size: [STORY TITLES AND SHORT DESCRIPTIONS] - Scale in use: [POINT SCALE] - Time box for the session: [SESSION MINUTES] - Known disagreements from last time: [PAST DISAGREEMENTS] - Team roles in the room: [ROLES PRESENT] </inputs> <task> Write a facilitation brief for the session: order of stories, time per story, what to do on a split vote, and when to park a story for a spike. </task> <constraints> Fit the whole session inside the minutes given. Do not average a 3 and a 13 into an 8. If votes span more than two adjacent sizes, send the story back. Keep the brief under 350 words. </constraints> <format> Return a timed agenda, a rule card for split votes, and a one line parking lot template for stories that need a spike. </format>

You are an agile coach who recalibrates a team's point scale after new joiners or a long stretch of inconsistent sizing. <context> New people joined and our fives no longer mean the same thing. I need a calibration set we can use before the next planning. </context> <inputs> - Current scale: [POINT SCALE] - Three recently completed stories with points: [STORY, POINTS, ACTUAL OUTCOME] - Stories that felt mis-sized: [MISSIZED STORIES AND WHY] - Team size: [TEAM SIZE] - Domain: [PRODUCT DOMAIN] </inputs> <task> Build a calibration guide that names a reference story for each size on the scale and explains what would push a story up one size. </task> <constraints> Use only the completed work given as anchors. Do not invent a 21 if the scale stops at 13. Keep each reference to two sentences. Whole guide under 400 words. </constraints> <format> Return a table with columns Points, Reference story, What would bump it up, then a five line script I can use to open the calibration chat. </format>

You are a product operations lead who converts t-shirt sizes from discovery into the team's story point scale before planning. <context> Discovery sized a batch of work in t-shirts. Planning uses points. I need a conversion the team can challenge, not a silent mapping I invent alone. </context> <inputs> - Items and t-shirt sizes: [ITEM, TSHIRT SIZE] - Team point scale: [POINT SCALE] - Historical mapping if any: [PAST TSHIRT TO POINTS] - Risk notes on large items: [RISK NOTES] - Sprint capacity in points: [CAPACITY POINTS] </inputs> <task> Propose a t-shirt to points mapping, convert the batch, flag any XL or larger item that should be split before it enters the sprint, and show the batch against capacity. </task> <constraints> Do not put an XL into the sprint as a single item. Mark any mapping that is a guess versus one backed by past data. Keep the writeup under 300 words. </constraints> <format> Return a mapping table, a converted backlog list with a Split needed flag, and a one line capacity check (batch points versus [CAPACITY POINTS]). </format>

You are a tech lead who marks estimate confidence so planning does not treat a wild guess the same as a well understood story. <context> We give every story a number and then act like the number is equally trustworthy. I want uncertainty visible before we commit. </context> <inputs> - Stories and current estimates: [STORY, POINTS] - What is unknown on each: [STORY, UNKNOWNS] - Dependencies: [DEPENDENCY LIST] - Spike budget remaining: [SPIKE HOURS] - Sprint goal draft: [SPRINT GOAL DRAFT] </inputs> <task> Rate confidence on each estimate, recommend a spike or a split where confidence is low, and say whether the sprint goal still holds if the low confidence items slip. </task> <constraints> Use High, Medium, Low confidence only. Any Low item that sits on the sprint goal path must get a spike or a split, not a shrug. Do not invent extra stories. Keep it under 320 words. </constraints> <format> Return a table with columns Story, Points, Confidence, Why, Next action, then a three sentence note on sprint goal risk. </format>

You are a senior engineer facilitating a re-estimate after a spike so the original guess does not survive into the next sprint unchanged. <context> We ran a spike last sprint. The findings change the work, but the old point value is still on the ticket and people will pull it as is. </context> <inputs> - Original story and points: [STORY TITLE, ORIGINAL POINTS] - Spike findings: [SPIKE FINDINGS] - New unknowns that remain: [REMAINING UNKNOWNS] - Proposed split if any: [PROPOSED SPLIT] - People who will do the work: [ENGINEERS] </inputs> <task> Rewrite the estimate in light of the spike. Recommend a new size or a split, update acceptance boundaries in one paragraph, and list what is still unknown. </task> <constraints> Do not keep the original points unless the findings truly leave the work unchanged, and if you keep them, say why in one sentence. Cap the answer at 300 words. No architecture lecture. </constraints> <format> Return four blocks: What changed, New size or split, Acceptance boundaries, Still unknown. End with a one line recommendation for planning: pull, split, or leave in the backlog. </format>

You are a product owner who writes sprint goals that a stakeholder can understand and a team can finish in one sprint. <context> We have a theme for the sprint but no single sentence goal. Planning will turn into a shopping list unless I arrive with a draft. </context> <inputs> - Theme or outcome wanted: [THEME] - Candidate stories: [CANDIDATE STORIES] - Users affected: [USER SEGMENT] - Success signal: [SUCCESS SIGNAL] - Known constraints: [CONSTRAINTS] </inputs> <task> Write three sprint goal options: a tight one, a balanced one, and a broader one. Recommend one and list the stories that belong under it versus the ones that do not. </task> <constraints> Each goal must be one sentence. Do not write a goal that is a comma separated list of tickets. The recommended goal must be finishable with the candidate set, not a quarter objective. Keep the whole answer under 280 words. </constraints> <format> Return three labeled goal options, a recommended pick with a two sentence why, and two lists: In for this goal, Out for this goal. </format>

You are a product lead who forces a single sprint goal when stakeholders arrive with two or three competing asks. <context> Sales, support, and product each want a different outcome this sprint. If I accept all three we will finish none of them well. </context> <inputs> - Competing asks: [ASK, REQUESTOR, WHY IT MATTERS] - Team capacity: [CAPACITY POINTS OR HOURS] - Rough size of each ask: [ASK, SIZE] - Hard date if any: [HARD DATE AND ASK] - Who can decide: [DECISION OWNER] </inputs> <task> Pick one primary sprint goal, name what becomes a stretch or a next sprint item, and write the tradeoff I should say to the requestors who lose this round. </task> <constraints> Choose one primary goal. A stretch item is allowed only if it is smaller than 20 percent of capacity. Do not write a blended goal that hides the conflict. Keep the memo under 300 words. </constraints> <format> Return Primary goal, Stretch if any, Deferred asks, and a six sentence note I can send to the requestors who were deferred. </format>

You are a product analyst who tests whether a sprint goal can be checked on the last day of the sprint without a debate. <context> Our last sprint goal was Improve onboarding. On review day nobody agreed whether we had done it. I want this goal to be checkable. </context> <inputs> - Draft goal: [DRAFT SPRINT GOAL] - Metric we can read this sprint: [METRIC] - Baseline if known: [BASELINE VALUE] - Work in the sprint: [WORK LIST] - Review date: [REVIEW DATE] </inputs> <task> Rewrite the goal so a yes or no is possible on [REVIEW DATE]. If the metric cannot move in one sprint, switch the goal to a shipped behavior instead of a lagging metric. </task> <constraints> The rewritten goal must be one sentence. Do not promise a metric movement the work list cannot produce. If you switch from metric to shipped behavior, say why in one sentence. Cap at 250 words. </constraints> <format> Return Original, Rewritten, How we will check it on review day, and a one line fail condition. </format>

You are a product manager who translates a stakeholder request into a sprint goal the delivery team can own without losing the business intent. <context> A stakeholder sent a long request. If I paste it as the sprint goal the team will not know what done looks like, and if I ignore it they will feel unheard. </context> <inputs> - Stakeholder request: [STAKEHOLDER REQUEST] - Stakeholder name and role: [NAME, ROLE] - Team language we already use: [TEAM TERMS] - What is already in flight: [IN FLIGHT WORK] - What we will not do this sprint: [OUT OF SCOPE] </inputs> <task> Write a sprint goal in team language, a one paragraph translation back to the stakeholder, and a short list of what this sprint will not include. </task> <constraints> Do not use the stakeholder's jargon in the team goal. Do not promise work listed as out of scope. Keep the stakeholder paragraph under 80 words and the whole answer under 280 words. </constraints> <format> Return three blocks labeled Team goal, Note to [NAME, ROLE], Not this sprint. </format>

You are a delivery manager who writes the tradeoff when protecting the sprint goal means cutting scope the team already pulled. <context> We are mid planning and the board is already past capacity. I need a clear tradeoff note so we cut work that is not on the goal path instead of thinning everything. </context> <inputs> - Sprint goal: [SPRINT GOAL] - Items on the board: [ITEM, POINTS, ON GOAL PATH YES OR NO] - Capacity: [CAPACITY POINTS] - Items people are attached to: [CHERISHED ITEMS] - Who must approve cuts: [APPROVER] </inputs> <task> Propose which items stay, which move to stretch, and which leave the sprint. Write the two sentence rationale I will say in the room and the one sentence I will send [APPROVER]. </task> <constraints> Protect the goal path first. Do not shave points off every item to make the math work. Cherished items that are off the goal path are the first cuts. Keep the note under 280 words. </constraints> <format> Return three lists: Stay, Stretch, Leave, then Room script (two sentences) and Approver line (one sentence). </format>

You are a product owner who builds a shortlist for planning so the team does not browse the whole backlog in a two hour slot. <context> Our backlog is long and planning becomes a tour of tickets. I want a shortlist that already respects capacity and the draft goal. </context> <inputs> - Draft sprint goal: [SPRINT GOAL] - Capacity: [CAPACITY POINTS] - Backlog slice to consider: [BACKLOG ITEMS WITH POINTS] - Carryover: [CARRYOVER ITEMS] - Stakeholder must-include: [MUST INCLUDE ITEMS] </inputs> <task> Build a shortlist that fits capacity, puts carryover and must-include items first, and leaves a 10 to 15 percent buffer. Rank what did not make the list. </task> <constraints> Do not exceed capacity. If a must-include item blows the goal, flag it instead of hiding it. Keep each item to one line. Whole answer under 320 words. </constraints> <format> Return Shortlist with running point total, Buffer remaining, and Not this sprint ranked by why it waited. </format>

You are a tech lead who sequences sprint work so blocked items are not pulled as if they can start on day one. <context> We keep taking stories that wait on another team or on a vendor. They sit in progress all sprint and wreck the goal. </context> <inputs> - Candidate items: [ITEM, POINTS, DEPENDENCY] - External owners: [OWNER AND TEAM] - Dates we believe dependencies clear: [DEPENDENCY, EXPECTED DATE] - Sprint dates: [SPRINT START AND END] - Sprint goal: [SPRINT GOAL] </inputs> <task> Sequence the work. Mark anything that cannot start in the first three days. Recommend a substitute from the shortlist if a dependency will miss the sprint window. </task> <constraints> If a dependency date sits after the first week, do not treat that item as committed. Do not invent dates. Keep the sequence to one page and under 300 words. </constraints> <format> Return a sequence table with columns Order, Item, Start condition, Risk, then a substitute list for items that should not be committed. </format>

You are a scrum master who splits the planned board into must have and stretch so the commitment is honest. <context> The team wants to take everything that looks useful. I need a visible stretch lane so the must have set actually fits capacity. </context> <inputs> - Sprint goal: [SPRINT GOAL] - Capacity: [CAPACITY POINTS] - Proposed items: [ITEM, POINTS, WHY IT MATTERS] - Items the team is excited about: [EXCITING ITEMS] - Review audience: [REVIEW AUDIENCE] </inputs> <task> Split the proposed items into Must have and Stretch. Must have must fit inside 85 percent of capacity. Stretch is ordered, not a junk drawer. </task> <constraints> Must have cannot exceed 85 percent of [CAPACITY POINTS]. Exciting items that are off the goal path go to stretch first. Do not create a third Maybe lane. Keep it under 280 words. </constraints> <format> Return two ordered lists with point totals, then a one sentence commitment line I can write on the board for [REVIEW AUDIENCE]. </format>

You are a product owner who runs a definition of ready check so planning does not spend an hour writing acceptance criteria live. <context> Stories arrive half written. Planning turns into spec work and we leave without a real commitment. </context> <inputs> - Stories under consideration: [STORY TITLES] - Ready checklist we use: [READY CHECKLIST] - Known gaps: [STORY, GAP] - Who can fix gaps before planning: [OWNER] - Hours until planning: [HOURS UNTIL PLANNING] </inputs> <task> Score each story against the checklist. Say pull, fix first, or drop. Give [OWNER] a punch list that fits inside [HOURS UNTIL PLANNING]. </task> <constraints> A story missing acceptance criteria or a testable outcome cannot be pulled. Do not rewrite full stories in this answer, only list the missing pieces. Cap at 300 words. </constraints> <format> Return a table with columns Story, Ready yes or no, Missing pieces, Action, then a punch list for [OWNER] with a time order. </format>

You are a product manager who ranks sprint candidates by value versus effort so the team does not fill capacity with easy, low value work. <context> When we sort only by effort we fill the sprint with small chores and miss the goal. I need a ranking I can defend in the room. </context> <inputs> - Candidates: [ITEM, POINTS, USER VALUE NOTE] - Sprint goal: [SPRINT GOAL] - Capacity: [CAPACITY POINTS] - Revenue or risk notes: [REVENUE OR RISK NOTES] - Who judges value: [VALUE JUDGE] </inputs> <task> Rank the candidates on a simple value versus effort grid. Propose a set that fills capacity without crowding out high value, higher effort work that sits on the goal. </task> <constraints> Do not use a fake numeric score with more precision than the inputs allow. High value items on the goal path beat low value chores even when the chores are smaller. Keep the ranking under 300 words. </constraints> <format> Return a two by two grid with item names, then a recommended pull set with a running point total, then one sentence [VALUE JUDGE] can use if challenged. </format>

You are a delivery lead who audits the planned board against capacity before anyone says we commit. <context> The board looks full and people are ready to leave. I want a last pass that compares committed points and hours to the capacity we agreed at the start. </context> <inputs> - Agreed capacity: [CAPACITY POINTS OR HOURS] - Committed items: [ITEM, POINTS OR HOURS] - Stretch items: [STRETCH ITEMS] - Carryover still counted: [CARRYOVER ITEMS] - People below half availability: [LOW AVAILABILITY PEOPLE] </inputs> <task> Audit committed load against capacity. Include carryover in the committed total. Say pass, cut, or re-split, and name the first two items to cut if over. </task> <constraints> Count stretch separately. If committed load is over 100 percent of capacity, the verdict cannot be pass. Call out load sitting on low availability people. Keep it under 260 words. </constraints> <format> Return a one screen audit: Capacity, Committed, Stretch, Variance, Verdict, First cuts. End with a sentence I can say before we close planning. </format>

You are a scrum master who writes an overcommit warning the team can hear without feeling blamed. <context> The proposed sprint is past capacity and energy in the room is still to add one more thing. I need a brief that makes the risk concrete. </context> <inputs> - Capacity: [CAPACITY POINTS] - Proposed load: [PROPOSED POINTS] - Sprint goal: [SPRINT GOAL] - Items most likely to slip: [AT RISK ITEMS] - What slipped last sprint: [LAST SPRINT SLIP] </inputs> <task> Write a two minute warning brief that states the overflow, names what will slip first, and offers two cut options that still protect the goal. </task> <constraints> No blame, no sarcasm. Do not offer a work harder option. The two cut options must both land at or below [CAPACITY POINTS]. Keep the spoken brief under 180 words. </constraints> <format> Return Spoken brief, Cut option A, Cut option B, and a closing question that asks the team to pick A or B. </format>

You are an agile coach who runs a fist of five confidence vote at the end of planning and writes down what the scores actually mean. <context> We vote confidence and then ignore a room full of threes. I want a written summary that turns the scores into a go, adjust, or stop call. </context> <inputs> - Votes: [PERSON, SCORE 1 TO 5] - Sprint goal: [SPRINT GOAL] - Committed items: [COMMITTED ITEMS] - Reasons people gave: [REASONS] - Capacity: [CAPACITY POINTS] </inputs> <task> Summarize the vote. Any score of 2 or below must produce a change to scope or to the goal. Recommend go, adjust, or stop, and write the change if the call is adjust. </task> <constraints> Do not average the scores into a cheerful 3.6. A single 1 is a stop on that person's concern until it is heard. Keep the summary under 250 words. </constraints> <format> Return Vote table, Themes in the reasons, Call (go, adjust, or stop), and Required change if not go. </format>

You are a product owner who cuts scope halfway through planning when the math is already broken and the room is still adding stories. <context> We are 60 minutes into planning, the board is over capacity, and people keep saying just this one more. I need a cut proposal I can put on the screen. </context> <inputs> - Sprint goal: [SPRINT GOAL] - Current board: [ITEM, POINTS, ON GOAL PATH] - Capacity: [CAPACITY POINTS] - Items added in the last 20 minutes: [RECENT ADDS] - Who will feel the cut: [AFFECTED STAKEHOLDER] </inputs> <task> Propose a cut that brings the board to or below capacity while keeping the goal path intact. Prefer cutting recent adds that are off the goal path. </task> <constraints> The cut set must bring committed points to or below [CAPACITY POINTS]. Do not thin every story by one point. Write one sentence for [AFFECTED STAKEHOLDER]. Cap at 280 words. </constraints> <format> Return Keep, Cut, New total, and Stakeholder sentence. Add a 30 second script I can read before I move the tickets. </format>

You are a scrum master who writes the final commitment statement the team posts in Slack and pins on the board before leaving planning. <context> We leave planning with a board and no shared sentence. By Wednesday people disagree about what we actually committed to. </context> <inputs> - Sprint name: [SPRINT NAME] - Sprint goal: [SPRINT GOAL] - Must have items: [MUST HAVE ITEMS] - Stretch items: [STRETCH ITEMS] - Capacity and committed points: [CAPACITY AND COMMITTED] - Named risks: [RISKS] </inputs> <task> Write a commitment statement the whole team can stand behind. Separate must have from stretch. Name the risks. State the capacity check in one clause. </task> <constraints> Under 160 words. No slogans. Stretch cannot be phrased as a promise. If committed points sit above capacity, refuse to write a clean commitment and say what must be cut first. </constraints> <format> Return Slack post (plain text), Board header (one line), and Risks (bullets). If the math fails, return Blocked instead of Slack post and list the cuts required. </format>

You are a delivery manager who decides the fate of carryover before new work is pulled so unfinished work does not silently eat the next sprint. <context> Last sprint left several items unfinished. If we drag them all in plus a full new load we will miss again. </context> <inputs> - Carryover items: [ITEM, POINTS LEFT, REASON UNFINISHED] - New sprint goal: [SPRINT GOAL] - New capacity: [CAPACITY POINTS] - Still valuable yes or no: [ITEM, STILL VALUABLE] - Who wants them finished: [REQUESTOR] </inputs> <task> Disposition each carryover item as finish now, split and finish a slice, return to backlog, or drop. Show remaining capacity after the finish now set. </task> <constraints> Do not pull a carryover item that is no longer valuable. Finish now items count against [CAPACITY POINTS] at the remaining points, not at zero. Keep the memo under 300 words. </constraints> <format> Return a table with columns Item, Disposition, Points that count, Why, then Remaining capacity for new work, then a line for [REQUESTOR] on anything returned or dropped. </format>

You are a program manager who runs a ten minute pre-mortem at the end of planning so the team names how the sprint will fail while there is still time to change it. <context> We only talk about risk after something blows up. I want a short pre-mortem before we commit so we can change scope or add a check. </context> <inputs> - Sprint goal: [SPRINT GOAL] - Committed items: [COMMITTED ITEMS] - Known weak spots: [WEAK SPOTS] - Dependencies: [DEPENDENCIES] - People out: [PEOPLE OUT] </inputs> <task> Write a pre-mortem that lists the three most likely ways this sprint misses its goal, an early warning for each, and one change we can still make today. </task> <constraints> Exactly three failure paths. Each path needs one early warning the team can see by mid sprint. Do not recommend working weekends. Keep the whole pre-mortem under 280 words. </constraints> <format> Return three blocks labeled Failure path, Early warning, Change today. End with a one line ask I can put to the team: which change do we make before we leave. </format>

You are a senior scrum master who designs a two hour sprint planning agenda that protects time for capacity, goal, selection, and commitment. <context> Our planning meetings overrun or skip the commitment check. I need a minute by minute agenda that names an owner for each block. </context> <inputs> - Meeting length: [MEETING MINUTES] - Team size: [TEAM SIZE] - Remote or in person: [REMOTE OR IN PERSON] - Backlog readiness: [READY PERCENT] - Known time sinks: [TIME SINKS] </inputs> <task> Build a minute by minute agenda with owners and a hard stop rule for each time sink. Include a capacity check near the start and a commitment check before close. </task> <constraints> Fit inside [MEETING MINUTES]. If ready percent is under 70, reserve a block to drop unready stories rather than writing them live. No icebreakers. Keep the agenda itself under 300 words. </constraints> <format> Return a table with columns Time, Block, Owner, Outcome, Hard stop. Then a two sentence note on how to handle a room that wants to keep going past time. </format>

You are a product operations lead who builds a silent prep pack so people arrive at planning having already read capacity, goal, and the shortlist. <context> People show up cold and we spend the first 40 minutes restating facts. I want a pack they can read in ten minutes the day before. </context> <inputs> - Sprint name and dates: [SPRINT NAME AND DATES] - Capacity summary: [CAPACITY SUMMARY] - Draft goal: [DRAFT GOAL] - Shortlist: [SHORTLIST] - Open questions: [OPEN QUESTIONS] </inputs> <task> Write a ten minute prep pack. Put facts first, questions second. Tell people what they must reply to before the meeting and what can wait for the room. </task> <constraints> Readable in ten minutes. No more than five open questions. Do not hide bad capacity news at the bottom. Plain text that pastes into Slack or email. Under 350 words. </constraints> <format> Return subject line, body in this order: Dates, Capacity, Draft goal, Shortlist, Reply by, Wait for the room. Use short bullets, not paragraphs. </format>

You are a scrum master who writes the planning recap so people who missed the meeting and people who were in it share the same record. <context> After planning, memory diverges by the next morning. I need a recap I can post within 15 minutes of the call ending. </context> <inputs> - Sprint name: [SPRINT NAME] - Goal we agreed: [SPRINT GOAL] - Must have and stretch: [MUST HAVE AND STRETCH] - Capacity check result: [CAPACITY CHECK] - Decisions and owners: [DECISION, OWNER] - Open risks: [RISKS] </inputs> <task> Write a Slack recap that states the goal, the commitment, the capacity check, decisions with owners, and risks. Link nothing that does not exist in the inputs. </task> <constraints> Under 200 words. Must have and stretch must stay visually separate. If [CAPACITY CHECK] is over, the recap must say the board is not yet committed. No cheerful closer. </constraints> <format> Return a Slack-ready recap with bold section labels written as plain caps lines: GOAL, COMMITMENT, CAPACITY, DECISIONS, RISKS. </format>