In short
Sprint planning meeting notes should record what the board does not - the sprint goal in one sentence, what was left out and why, capacity caveats such as holidays, risks and dependencies named, and any decision about scope. The tickets themselves already live on the board.
Sprint planning meeting notes should record what the board cannot: the sprint goal in one sentence, what was left out and why, capacity caveats, the risks people named, and any decision about scope. The tickets already live on the board, with estimates and owners. Copying them into the notes adds nothing. The reasoning behind them is what disappears by the second week.
This guide covers what to write down during sprint planning, a template to copy, a sprint planning agenda that makes the notes easy, and where the notes go afterwards.
How to take sprint planning meeting notes
- Pick a note-taker who is not sharing the board. The person moving tickets cannot also write down why.
- Open a copy of the template before the meeting. Fill in the sprint number, dates and who is attending.
- Write down capacity first. Who is away, part-time, on support duty or new to the team. This explains the plan later.
- Write the sprint goal as soon as it is agreed. One sentence. Read it back to the room.
- Record what was left out, and why. Every time a ticket that was discussed does not make it in, write one line.
- Write down every risk someone names. "If the Northwind API changes again, this slips" goes in, with who said it.
- Record decisions about scope. "We will ship the export without the PDF option" is a decision; add it to the team's decision log if it outlasts the sprint.
- Read the goal, exclusions and risks back before closing. Two minutes. Then post the notes where the team will see them.
Why the board is not enough
A sprint board is a good record of what: the tickets, their estimates, who picked them up. It is a poor record of why:
- Why this and not that. Three weeks later, someone asks why the billing fix was not in the sprint. The board shows it was not; only the notes say it was left out because it depended on another team.
- What the plan assumed. A sprint planned with two people on holiday looks overcommitted or undercommitted to anyone who did not know.
- What people were worried about. A risk named in planning and then realised is a lesson; a risk nobody wrote down is a surprise.
The notes are short because they only hold these things.
The sprint planning notes template
# Sprint <number> planning — <start date> to <end date>
**Attending:** <names>
**Capacity:** <who is away, part-time, on support, new>
## Sprint goal
<one sentence, an outcome, not a list of tickets>
## In, with reasons worth keeping
- <ticket or theme> — <why it is in, only if not obvious>
## Left out, and why
- <ticket or theme> — <reason: dependency, too big, lower priority>
## Risks and dependencies
- <risk> — <raised by> — <what we'll do if it happens>
## Scope decisions
- <decision> — <reason>
## Open questions
- <question> — <owner> — <by when>A filled-in example
# Sprint 14 planning — 6 Oct to 17 Oct
**Attending:** Ana, Tom, Priya, Marc
**Capacity:** Marc on holiday 13–17 Oct. Priya on support rota week 1.
## Sprint goal
Customers can export a month of Harbour reports as CSV.
## Left out, and why
- PDF export — needs the new renderer, not ready until sprint 16.
- Billing rounding bug — waiting on the payments team's fix.
## Risks and dependencies
- Northwind's API rate limits may slow large exports — raised by Tom —
test with their sandbox in week 1.
## Scope decisions
- CSV only this sprint; PDF follows. Agreed by Ana (product).
## Open questions
- Do exports need a date-range picker? — Ana — by 8 Oct.A sprint planning agenda that makes the notes easy
Most teams follow a version of this order. The notes above map onto it.
| Step | What happens | What goes in the notes |
|---|---|---|
| 1. Capacity | Who is available and how much | Capacity line |
| 2. Why this sprint | Product owner proposes the objective | Sprint goal (draft) |
| 3. What can be done | Team pulls items from the backlog and discusses them | In / left out, with reasons |
| 4. How | Team breaks items into work | Risks and dependencies |
| 5. Commit | Goal agreed, plan confirmed | Final sprint goal, scope decisions |
The Scrum Guide (2020 edition, checked 25 September 2026) describes sprint planning as answering why the sprint is valuable, what can be done, and how the chosen work will get done, and it makes the sprint goal an output of the meeting. You do not need to run Scrum to use this structure; most iterative teams plan with some version of it.
Writing a good sprint goal
A sprint goal is one sentence describing an outcome. It helps the team decide what to drop if the sprint runs short: anything that does not serve the goal goes first.
| Weak | Better |
|---|---|
| Complete tickets 142, 151, 155 and 160 | Customers can export a month of reports as CSV |
| Work on performance | The dashboard loads in under two seconds for the largest customer |
| Various fixes | Clear the three bugs blocking the Northwind rollout |
If the team cannot agree on one sentence, that is worth knowing too. Write down the disagreement.
Where the notes go afterwards
Post them where the team already looks: the sprint's page in your tracker, the team channel, or a planning document linked from the board. Then use them:
- At standups. The goal and the risks are the frame for "are we on track?" Standup meeting notes covers keeping those short.
- At the retrospective. Compare what happened with what the planning notes expected. The risks that came true, and the ones nobody named, are the best material a retro gets. See retrospective meeting notes.
- In the decision log. A scope decision that will matter after the sprint ends ("no PDF export until the renderer ships") belongs in the team's decision log, where it can be found in six months.
Recording sprint planning
Most teams do not need to. The board and short notes cover it, and planning often involves thinking out loud that people prefer not to have kept. If someone wants a recording, for example a team member in another time zone who cannot attend, ask the team first and say who will be able to hear it and for how long.
For a remote planning session that someone does record, Notey on a Mac records your microphone and the call's audio on two separate tracks and transcribes them on the device. After the meeting, you can search the transcript for the moment a risk was raised and play it back from that line. That is useful when the notes say "Tom raised rate limits" and you need to know exactly what Tom said. It does not replace the notes; a transcript of a two-hour meeting is not something anyone rereads.
Common mistakes
- Copying the board. It is already there.
- No sprint goal, or a goal that is a list of tickets.
- Exclusions not written down. The next planning meeting argues them again.
- Capacity forgotten. The sprint looks like a failure when it was planned for three people, not five.
- Notes posted nowhere. If the team cannot find them at the retro, they did not exist.
For where sprint planning sits among the other meetings a team runs, see types of meetings and the notes each one needs.
Frequently asked questions
What should sprint planning notes include?
The sprint goal, what was deliberately left out and why, who is away or part-time, the risks and dependencies someone named, and any decisions about scope. The list of tickets is on the board and does not need copying.
What is a sprint goal?
One sentence saying what the sprint is meant to achieve, as an outcome rather than a list of tickets. It gives the team a way to decide what to drop if the sprint runs short.
Who takes notes in sprint planning?
Anyone who is not running the meeting. Rotating the job works well; the person sharing the board is the worst choice, because they are busy moving tickets.
How long should sprint planning take?
The Scrum Guide sets a maximum of eight hours for a one-month sprint and says it is usually shorter for shorter sprints. Many teams on two-week sprints aim for one to two hours.
Should sprint planning be recorded?
Rarely necessary, since the board and short notes cover most of it. If someone wants to record it, ask the team first, and say who will be able to hear it.