Sprint Planning Meeting Template
Your sprint plan rarely survives its first day. That's not a discipline problem — it's a planning-meeting problem. Teams pull backlog items until the board looks satisfyingly full, skip the capacity math, and walk out with a sprint goal that three different people would phrase three different ways. By Tuesday the plan is a suggestion and the team is quietly descoping.
This template fixes the part that usually breaks. It forces the three decisions Scrum requires — what the sprint is for, what fits in it, and who's doing what — into a written record with an owner and a number next to every commitment.
What sprint planning is for
Sprint planning opens each sprint in Scrum. The Scrum Guide timeboxes it to a maximum of eight hours for a one-month sprint, and less for shorter ones. The meeting has one job: produce a sprint goal and a set of backlog items the team commits to, plus a plan for how the work gets done.
The failure mode is almost always the same. The discussion is good, the room agrees, and then everyone reconstructs the outcome from memory. The goal gets rewritten in the ticket tracker by whoever types fastest, and the capacity math that was argued about out loud never makes it into writing.
The template
1. Sprint goal
One sentence the whole team can repeat. If you can't say it in a sentence, the sprint is too broad.
| Field | Notes |
|---|---|
| Sprint goal | The one outcome this sprint exists to produce |
| Why it matters now | The user or business problem it moves |
| Definition of done | How the team will know the goal was met |
Write the goal first, before touching the backlog. A goal set after the items are picked is just a summary of the items — it can't make trade-off calls later in the sprint.
2. Capacity check
The part everyone skips. Before pulling a single item, work out how many hours the team actually has. Runn's guide to agile capacity planning suggests planning to roughly 80% utilization, leaving a buffer for the interruptions and unknowns every sprint hits.
| Field | Notes |
|---|---|
| People × days | e.g. 5 engineers × 10 working days |
| Less: holidays, PTO, on-call | Subtract anything that isn't sprint work |
| Usable hours per person per day | A common planning number is 6, to allow for meetings |
| Target utilization | Around 80%, so the plan survives reality |
| Committed capacity | The number you plan against |
The arithmetic: take five engineers, a two-week sprint, and six usable hours a day. That's 300 gross hours. Knock off a couple of days for PTO and on-call — call it 40 hours — and you're at 260. Plan to 80% of that, and you commit to roughly 208 hours of work. That number is a ceiling, not a goal.
3. Backlog pull
Now pull items until you hit the capacity number — not until the board looks full.
| Item | Points | Owner | Why it's in | Fits goal? |
|---|---|---|---|---|
| (e.g. Add OAuth to the API) | 5 | Name | Unblocks the partner integration | Yes |
Every item needs an owner and a one-line reason. If the reason is "it was in the backlog," it doesn't belong in the sprint.
4. Risk and dependencies
Things outside the team's control that could sink the sprint.
| Risk / dependency | Impact | Mitigation | Owner |
|---|---|---|---|
| Design for the new flow not ready | Blocks 3 stories | Confirm by day 2, else swap | Name |
5. Commitment record
The sprint's contract. Each committed item gets a name and a way to tell whether it actually shipped.
| Commitment | Owner | Definition of done | Status at next planning |
|---|---|---|---|
| OAuth endpoint live in staging | Name | Merge + staging test pass | Open / done / dropped |
How to run the meeting
The agenda follows the three questions the Scrum Guide says sprint planning has to answer.
- Why is this sprint valuable? (goal, ~15 min). The product owner sets up the goal and why it matters now. The team refines the wording until everyone can say it in one sentence. Don't move on until the sentence exists.
- What can be done this sprint? (select, ~45 min). Run the capacity math out loud, then pull items against it. The product owner proposes, the team estimates and commits. Say no out loud — it's easier than silently overcommitting.
- How will the work get done? (decompose, ~30 min). Break each selected item into tasks small enough that a single person can own them. You don't need every task estimated, just enough to expose hidden work.
Timebox the whole thing. A well-prepared team with a clean backlog can plan a two-week sprint in 60 to 90 minutes. If you're consistently blowing past that, the backlog isn't refined — fix refinement, not the agenda.
Why the plan still dies
Sprint planning is a meeting, so it inherits every meeting's failure mode: the outcome lives in people's heads until someone writes it down, and whoever writes it down filters it. The sprint goal gets polished into something nobody actually said, and the capacity math that justified a "no" gets lost, so the no gets walked back later.
This is the one place an AI meeting assistant genuinely earns its seat. If one joins the planning meeting and transcribes it, the goal is captured exactly as the team agreed to it — with the quote and the speaker attached — rather than re-typed from memory. Each commitment carries who said they'd own it. When next sprint's planning starts with a review of this sprint's commitments, the team checks against what was actually agreed, not what someone remembers agreeing to.
The template still matters, because the assistant fills whatever structure you hand it. A sprint plan without a capacity number and an owner per item is a wish list, whether a human or an AI types it.
The point
Sprint planning isn't where the work happens — it's where the team decides what the work is. The meeting has failed if anyone leaves unsure what the sprint is for or who's doing what. A one-sentence goal, a real capacity number, and an owner on every committed item turn a vague hour of discussion into a plan the team can actually hold. The rest is just execution.