Sprint Planning Notes Template
A sprint planning notes template records what the team commits to: the sprint goal, backlog items with estimates and owners, total vs capacity, items not taken and risks. Free to download in Word or PDF, no sign-up, with an example below.
Free. No sign-up.
Dalm is a Mac app that records a meeting — a call or a room — and drafts notes from the transcript. Get early access
Sprint planning notes answer two questions: what the team takes into the sprint, and why. The why is the sprint goal — one sentence, agreed before the meeting ends — and every item in the sprint backlog should serve it. The notes also keep the numbers honest: the total estimate next to the team’s capacity, so overcommitment shows up on paper rather than in week two. Items that were left out go on the record with a reason, and so do the risks that could move the goal, because those are the lines people come back to when the sprint changes course.
What’s in the template
The file follows a planning session from the goal down to the open questions:
- Header — team, sprint number and dates, attendees, and capacity: people available, days off, planned load.
- Sprint goal — one sentence: why this sprint matters.
- Sprint backlog — a table: number, item, estimate, owner, and notes or acceptance criteria.
- Total estimate vs capacity — one line under the table.
- Not taken / moved back to backlog — a table: item and reason.
- Risks and dependencies — a list.
- Questions to clarify — a table: question, who clarifies and by when.
The terms sprint goal and sprint backlog are used here in their everyday Scrum sense; the template works the same whatever framework your team follows. It opens with one line on its purpose: notes from sprint planning — the sprint goal, the backlog items taken in with estimates and owners, capacity, and the risks that could move the goal.
Sprint planning example
Example (fictional). Names and events are invented.
| Team | Mobile app |
| Sprint | No. 21, |
| Attendees | Dmitry, Nastya, Ilya, Marina (product) |
| Capacity | 3 developers, Ilya off on ; about 24 points |
Sprint goal
Ship the full workspace invitation flow — from email to first sign-in.
Sprint backlog
| No. | Item | Estimate | Owner | Notes |
|---|---|---|---|---|
| 1 | Send invitation email | 3 | Dmitry | — |
| 2 | Accept-invitation screen | 5 | Nastya | Expired link shows a separate screen |
| 3 | Push notification on accepted invite | 5 | Ilya | — |
| 4 | Invitation logging | 2 | Dmitry | Taken as buffer |
Total: 15 of about 24 points.
Not taken
| Item | Reason |
|---|---|
| Roles and permissions on invite | Requirements incomplete |
Risks and dependencies
- If role requirements arrive mid-sprint, the goal may shift.
Questions to clarify
| Question | Who | By when |
|---|---|---|
| Role requirements from product | Dmitry asks Marina | Wednesday |
Two things here are worth copying. The team took in 15 points against about 24 of capacity and said so, leaving room for a half-known risk instead of filling the sprint to the brim. And the item with unclear requirements was not squeezed in — it went under “Not taken” with a reason, and the same unknown reappears as the one risk and as the one open question, which has a name and a day.
How to fill it in
Sprint planning notes are useful when they make the trade-offs visible. The four rules in the template are about that: settle the goal before anyone leaves the room, take in only work whose requirements are clear, put the total estimate and the capacity next to each other, and name the specific things — such as a dependency on another team — that could knock the goal off course.
- The goal is agreed before the meeting ends. Items serve the goal, not the other way round.
- Only items with clear requirements go in. Unclear ones go to “Not taken” with a reason.
- Compare total estimate with capacity so overcommitment is visible on paper.
- Risks name what could move the goal, e.g. a dependency on another team.
How to write a sprint goal
A sprint goal is one sentence that tells someone outside the team what will be different at the end of the sprint and why it matters. Write the outcome, not the work: if the sentence could be replaced by the list of tickets, it is not yet a goal. Two examples of the change:
- Vague: “Work on invitations.” Clear: “Ship the full workspace invitation flow — from email to first sign-in.”
- Vague: “Improve performance.” Clear: “Bring the search results page under one second on a mid-range phone, so we can switch the new search on for everyone.”
A clear goal earns its keep mid-sprint: when something has to give, the team can drop the items that do not serve it without a new meeting.
Sprint planning or another team meeting
| You need | Use |
|---|---|
| What the team takes into a sprint and why: goal, backlog, capacity | This sprint planning notes template |
| A daily check-in: yesterday, today, blockers | Daily standup notes template |
| What the team learned from the last sprint and the changes it commits to | Retrospective notes template |
| A status record for one project: milestones planned vs forecast, risks, dependencies | Project meeting summary template |
Every other template is on the templates page.
If you would rather not take notes at all
You can fill in this template by hand. If you would rather follow the discussion, Dalm is a Mac app that records the meeting — a call, or a conversation in the room through the Mac’s microphone — and drafts notes from the transcript to start from. The draft is its own document rather than this template filled in: you correct it line by line and save it as PDF, Word (.docx) or Markdown.
See plans · For teams
Questions
- What should be recorded in sprint planning?
- The sprint goal in one sentence; the backlog items the team takes in, each with an estimate, an owner and notes or acceptance criteria; the total estimate against capacity; the items not taken and why; the risks and dependencies that could move the goal; and the questions still to clarify, with who clarifies them and by when.
- How do you write a good sprint goal?
- Say in one sentence why the sprint matters to someone outside the team — an outcome, not a list of tasks. "Ship the full workspace invitation flow, from email to first sign-in" is a goal; "Do tickets 101 to 108" is a to-do list. A good goal also lets the team decide what to drop if the sprint gets tight.
- How do you check sprint capacity?
- Count the people available for the sprint, subtract days off and any planned load outside the sprint, and turn that into the same units the team estimates in. Then add up the estimates of the items taken in and write both numbers side by side — total vs capacity — so overcommitment is visible on paper before the sprint starts.
- Who attends sprint planning?
- The people who will do the work and the person who decides what matters most for the product — in Scrum terms, the developers and the product owner, often with a facilitator. Anyone the goal depends on, such as a designer or someone from another team, can join for the part that concerns them.
- Is the template free?
- Yes. The Word and PDF files download free, with no account and no e-mail address asked. The template is in English and carries no product name or branding, so you can switch estimates from points to hours, add columns and reuse it at every planning session.