Sprint planning meeting template (free, with example)

What’s in the template

The minutes open with these details:

• Team
• Sprint number and dates
• Date of planning meeting
• Facilitator (scrum master)
• Product owner
• Notes taken by
• Present
• Absent

Then the body follows the meeting in this order:

1. 1. Why this sprint — The product owner explains what matters most right now and what the sprint should change for users or the business. Five minutes.
2. 2. Sprint goal — One sentence the team writes together. If the goal needs three sentences, it is probably two goals.Sprint goal:
3. 3. Capacity — Working days per person minus leave, on-call, training and known meetings. Compare with the last three sprints' completed points or items before committing.Working days in sprint: · Per person (name, available days, notes): · Total available days: · Average completed last three sprints: · Planned capacity this sprint:
4. 4. Items pulled into the sprint — One line per item, in priority order: ID, title, estimate, and whether it serves the goal. Stop pulling when capacity is reached, not when the backlog runs out.ID: · Title: · Estimate: · Serves goal (yes / no): · Owner (if known):
5. 5. Dependencies — Anything an item needs from outside the team: an API, a design, a decision, access. Record who promised it and by when. An undated dependency is a risk, not a plan.Item: · Depends on: · Promised by (person / team): · Date:
6. 6. Risks and assumptions — What could make the goal miss, and what the team is assuming to be true. Keep to things that would change the plan if they turned out differently.
7. 7. Definition of done confirmed — Read it out or paste it here. Note any change agreed for this sprint, for example a new accessibility check.
8. 8. Commitment and first steps — Does the team agree the goal is achievable with this list? Record any item marked as a stretch. Note who starts on what tomorrow.Team commits (yes / with reservations): · Stretch items: · Day-one assignments:

At the end: sprint backlog and action items (pre-sprint and in-sprint), as tables you can keep across meetings.

The template

Download it as a Word file, or copy the text version into your own document.

Sprint Planning Notes

Team: 
Sprint number and dates: 
Date of planning meeting: 
Facilitator (scrum master): 
Product owner: 
Notes taken by: 
Present: 
Absent: 

1. Why this sprint
   [The product owner explains what matters most right now and what the sprint should change for users or the business. Five minutes.]

2. Sprint goal
   [One sentence the team writes together. If the goal needs three sentences, it is probably two goals.]
   Sprint goal:

3. Capacity
   [Working days per person minus leave, on-call, training and known meetings. Compare with the last three sprints' completed points or items before committing.]
   Working days in sprint:
   Per person (name, available days, notes):
   Total available days:
   Average completed last three sprints:
   Planned capacity this sprint:

4. Items pulled into the sprint
   [One line per item, in priority order: ID, title, estimate, and whether it serves the goal. Stop pulling when capacity is reached, not when the backlog runs out.]
   ID:
   Title:
   Estimate:
   Serves goal (yes / no):
   Owner (if known):

5. Dependencies
   [Anything an item needs from outside the team: an API, a design, a decision, access. Record who promised it and by when. An undated dependency is a risk, not a plan.]
   Item:
   Depends on:
   Promised by (person / team):
   Date:

6. Risks and assumptions
   [What could make the goal miss, and what the team is assuming to be true. Keep to things that would change the plan if they turned out differently.]

7. Definition of done confirmed
   [Read it out or paste it here. Note any change agreed for this sprint, for example a new accessibility check.]

8. Commitment and first steps
   [Does the team agree the goal is achievable with this list? Record any item marked as a stretch. Note who starts on what tomorrow.]
   Team commits (yes / with reservations):
   Stretch items:
   Day-one assignments:

Sprint backlog
ID | Item | Estimate | Serves goal | Dependency

Action items (pre-sprint and in-sprint)
Action | Owner | Due

Example: filled-in sprint planning

What the template looks like once it’s been used. The organisation and people are made up.

Action items

Tips for sprint planning

• Write the sprint goal before pulling items in. Choosing items first and inventing a goal to cover them produces a goal nobody uses.
• Put the capacity arithmetic in the notes. When the sprint runs short, the team can see whether the plan or the estimate was wrong.
• Record who promised each dependency and the date. "Platform team, this week" is not a dependency you can chase.
• Mark stretch items as stretch in the notes and on the board, so a sprint review does not count them as misses.
• Note day-one assignments. The first morning of a sprint is often lost to deciding who starts on what.
• If planning takes more than half a day for a two-week sprint, bring it to the retro; the backlog probably was not ready.

Related templates

• Daily standup template — Fifteen minutes, three questions per person, and a place to park anything that needs a longer conversation.
• Sprint retrospective template — What went well, what didn't, ideas, and the one to three actions the team actually commits to.
• Project kickoff meeting template — The one meeting where scope, roles and how the project will communicate are written down before anyone starts work.
• Meeting notes with action items template — Notes built around a running action register, for recurring meetings where last week's actions are this week's first agenda item.
• All meeting minutes templates

Or let the notes write themselves

A template helps when you’re the one typing. If you’d rather not be, an AI note taker can draft the summary and action items for you. Most send a bot into the call; QuietNote captures from your own computer instead, so nothing joins the meeting and you decide when capture starts. It’s in private beta. Whatever you use, read the draft before you send it, and tell attendees you’re recording where the rules require it.