Act as an experienced Scrum facilitator and delivery manager. Build a proposed sprint plan from the information below. Do not treat this as a promise to deliver every item; protect the team’s stated capacity and call out uncertainty. Sprint context: [SPRINT CONTEXT] Team capacity and availability: [TEAM CAPACITY] Candidate backlog items: [BACKLOG ITEMS] Known dependencies, dates, and risks: [DEPENDENCIES AND RISKS] Definition of Done and current carryover: [DONE CRITERIA] First, identify a single sprint goal that describes the outcome, not a list of tickets. Then select only the work that fits capacity after allowing a visible contingency buffer for interrupts, review, and defects. Preserve any fixed-date dependency before lower-value work, but do not silently prioritize an item just because it is listed first.
Produce these sections: 1. Sprint goal: one sentence, plus the user or business outcome it supports. 2. Proposed commitment: a table with item, rationale, owner or owning role, estimate/capacity impact if supplied, dependency, and acceptance evidence. 3. Sequencing: a day-by-day or milestone plan showing what must start early, handoffs, review points, and the latest safe date for dependent work. 4. Not selected: items deferred, with a short reason such as capacity, unclear acceptance criteria, or blocked dependency. 5. Risks and planning decisions: assumptions, scope cuts to make first if capacity changes, and questions for the planning meeting. Use only the supplied facts. If a named owner, estimate, or acceptance criterion is absent, mark it “unassigned,” “not estimated,” or “needs clarification”; do not invent it. Ask up to 3 clarifying questions only if a required input is missing. Before answering, check that total selected work does not exceed stated capacity and that every committed item has a testable completion condition. Flag any conflict rather than hiding it.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [SPRINT CONTEXT] | Enter the sprint dates, product area, objective, and any fixed release or event. | Two-week sprint, Oct. 6–17; improve trial-to-paid checkout before an Oct. 20 webinar. |
| [TEAM CAPACITY] | Enter each available person or role, planned availability, and known non-project time. | Maya engineer 7 days, Luis engineer 8 days, Priya designer 3 days, Jordan QA 4 days; reserve 15% for support. |
| [BACKLOG ITEMS] | Paste candidate work with descriptions, estimates, priority signals, and any proposed owners. | Checkout error tracking (2d, Maya); annual-plan checkout flow (5d, Luis + 1d Priya); pricing copy test (1d Priya, 1d Maya); invoice export bug (2d, Maya); onboarding survey (3d, Luis). |
| [DEPENDENCIES AND RISKS] | List external teams, approvals, technical dependencies, deadlines, and likely interruptions. | Legal must approve annual-plan terms by Oct. 8; payment provider sandbox is unstable; support expects a billing spike after webinar. |
| [DONE CRITERIA] | Enter the team’s Definition of Done and unfinished work carried from the prior sprint. | Code reviewed, QA passed in staging, analytics event verified, release note written. Carryover: invoice export bug is half diagnosed. |
How to use
- Paste the sprint dates, available capacity, and only backlog items that could plausibly be considered.
- Check the proposed commitment against actual capacity, including support, ceremonies, and leave.
- Use the sequencing section to assign handoffs and identify decisions needed before the sprint starts.
- Follow up with: “Re-plan this if [PERSON] loses two days and keep the sprint goal intact.”
Variations
Refinement agenda
Use before backlog refinement rather than the commitment meeting.
Create a 45-minute backlog-refinement agenda from [BACKLOG ITEMS] for [TEAM]. For each item, identify the user outcome, missing acceptance criteria, dependency, sizing question, and whether it is ready for sprint planning. Produce a timed agenda, a ready/not-ready table, and a short list of decisions the product owner must make. Do not estimate work or assign owners when the input does not support it. Ask up to 3 questions only if a required input is missing. Check that every agenda item ends with a decision or next action.
Mid-sprint recovery
Use when a sprint is at risk and scope must be reset.
Help me recover this sprint without masking missed work. Sprint goal: [SPRINT GOAL]. Status by item: [CURRENT STATUS]. Remaining capacity: [REMAINING CAPACITY]. New issue or interruption: [NEW ISSUE]. Produce a keep/cut/defer table, a revised sequence, and a concise stakeholder update that states impact, decision, and next checkpoint. Keep only work necessary for the sprint goal unless a fixed obligation requires otherwise. Do not invent completion dates. Ask up to 3 questions only if needed. Check that the revised plan fits remaining capacity.
Sprint review brief
Use to prepare a factual sprint review.
Turn these delivery notes into a sprint review brief. Sprint goal: [SPRINT GOAL]. Completed work and evidence: [COMPLETED WORK]. Unfinished work and reason: [UNFINISHED WORK]. Outcome data or feedback: [RESULTS]. Produce a one-page review with goal status, completed outcomes, demos to show, variance from plan, and one improvement for the next sprint. Separate facts from hypotheses and do not claim impact without evidence. Ask up to 3 questions only if inputs needed for a section are absent. Check that unfinished work is visible rather than reframed as complete.
Tips
- Plan to effective capacity, not nominal hours; leave room for support, code review, defects, and meetings before selecting work.
- A sprint goal should survive a scope cut: if removing one ticket makes the goal meaningless, the goal is probably a ticket list.
- Put external approvals and cross-team work at the start of the sequence, with a decision date rather than a vague dependency.
- Treat carryover as new planning input and ask why it carried over before recommitting it.
FAQ
Can AI estimate our sprint capacity?
It can organize estimates and expose arithmetic conflicts, but it cannot know your team’s velocity or interruption load unless you provide it. Use recent completed sprints as the better reference.
Should every backlog item have an owner during planning?
Someone should own moving each committed item forward, but avoid assigning work solely from an AI suggestion. Mark gaps for the team to decide.
What should we do with unestimated work?
Keep it out of a firm commitment unless it is a small discovery task with a bounded outcome. The prompt will label it as needing clarification.