Sprint Planning Template — MickyMarvels LLC

4 hrs

Max for 1-month Sprint

2 hrs

Typical 2-week Sprint

Key outputs

Whole

Team attends

Before Sprint Planning — Pre-Flight Checklist

24–48 hrs before

Product Backlog is ordered and refined. The top 1.5× Sprint's worth of stories have clear acceptance criteria and estimates. Stories that are not refined should not enter this Sprint.

Sprint Goal direction is clear. The Product Owner has a clear idea of what the most important objective is for this Sprint and can articulate it to the team.

Team availability is confirmed. You know who is on leave, who has reduced availability, and any external commitments that will affect Sprint capacity.

Last Sprint's velocity is reviewed. Use the average of the last 3 Sprints as your baseline capacity for this Sprint.

Technical dependencies are identified. Any stories blocked by external dependencies should be flagged before planning begins.

Definition of Done is visible and agreed. Everyone must know what "done" means before committing to any work.

Crafting the Sprint Goal

First 15 minutes

Sprint Goal Formula

"By delivering [key capability or outcome], we will [create business/user value], which will be confirmed when [measurable indicator]."

✅ Good: "By enabling users to complete checkout without creating an account, we will reduce cart abandonment for guest shoppers, which we will confirm when the guest checkout flow passes all acceptance tests."

❌ Bad: "Complete stories MM-14, MM-15, and MM-16."

💡

The Sprint Goal is the ONLY thing that protects the Sprint from scope changes. A weak or absent goal means anything can be changed mid-Sprint. A strong goal gives the team the power to say no.

Sprint Planning Agenda

Full session

Time	Activity	Owner	Notes
0:00–0:15	Open & Sprint Goal PO presents the Sprint Goal and top priority backlog items. Team asks clarifying questions.	Product Owner	Goal must be agreed before selecting items
0:15–0:45	Capacity Check Team calculates available capacity for this Sprint accounting for leave, meetings, and commitments.	Scrum Master	Use capacity table below
0:45–1:30	Story Selection (Part 1 — What) Team pulls stories from the top of the backlog until capacity is reached. Each story is understood and agreed.	Team + PO	PO answers questions; team decides what fits
1:30–2:00	Task Breakdown (Part 2 — How) Developers break selected stories into tasks, identify technical approaches, and flag risks.	Developers	PO and SM may observe but do not direct
2:00–2:10	Commitment Check Team confirms they believe the Sprint Goal is achievable. Final Sprint Backlog is locked.	Scrum Master	Ask: "Is there anything that might prevent us from meeting this Sprint Goal?"
2:10–2:15	Close Sprint board is updated. Start date confirmed. Next Daily Scrum time agreed.	Scrum Master	Board must be ready before the first Daily Scrum

Capacity Planning Table

Fill in per Sprint

Team Member	Role	Days Available	Ceremony Hours	Net Capacity	Story Points Est.
_____________	_______	___	___	___	___
_____________	_______	___	___	___	___
_____________	_______	___	___	___	___
_____________	_______	___	___	___	___
TOTAL SPRINT CAPACITY				___	___

📐

Capacity formula: (Working days × 6 hours) − ceremony time = available hours. Convert to story points using your team's average velocity per person per day from previous Sprints.

Common Sprint Planning Mistakes

❌ Things to Avoid

Pulling in stories without acceptance criteria
Skipping the Sprint Goal — just listing stories
PO assigning tasks to specific developers
Committing to more than historical velocity
Not accounting for leave and meetings in capacity
Skipping Part 2 (How) — going in blind on implementation
Letting planning run over timebox without permission

✅ Signs of a Great Sprint Planning

Everyone can state the Sprint Goal without looking at notes
Stories were refined before planning — no surprises
Team chose what to pull in — not the SM or PO
Tasks are broken down and owned
The team says "yes, we can do this" with confidence
Board is fully set up before first Daily Scrum
Finished in the timebox or earlier

Scrum Master Facilitation Tips

Start with Why, not What. Open the meeting by having the PO explain the business context — why this Sprint matters — before jumping into stories. It builds purpose and alignment.

Use a visible timer. Put a timer on the screen for each section. When the timebox for "story selection" ends, the team must commit to what they have — no exceptions.

Watch for over-commitment. If the team is selecting stories that significantly exceed their historical velocity, intervene early. Ask: "How confident are you about this story given our last 3 Sprint velocities?"

Protect Part 2 time. Many teams skip task breakdown. This is where risks are discovered. Protect at least 30% of planning time for Part 2 — the HOW matters as much as the WHAT.

End with a confidence vote. Before closing, do a fist-of-five vote (1–5 fingers). If anyone shows 1 or 2, find out why and address it before the Sprint starts.

MickyMarvels LLC

Practical Agile Mentoring · mickymarvels.info