Sprint planning template (copy-paste)

A sprint planning template is a simple, repeatable structure for capturing the output of planning: the sprint goal, the team’s capacity, the work selected, and whether the team believes it can finish. Its job is to make sure the same four things get decided every sprint — and that nothing important gets left implicit.

Copy the template below into whatever you plan in — a doc, a wiki page, your issue tracker, or TeamRetro. Fill it in during the meeting, top to bottom, in the order you run it.

The template

Copy this into your doc, wiki, or tracker and fill it in as you go:

# Sprint planning — Sprint #___
Dates: ___ to ___   ·   Team: ___

## Sprint goal
One sentence. What is meaningfully different or shippable when this sprint ends?
> ___

## Capacity this sprint
- Working days available: ___
- Known time off / holidays: ___
- Standing meetings & ceremonies: ___
- Support / on-call load: ___
- Realistic capacity: ___   (in the unit you plan in — points or days)

## Selected backlog items
| # | Item | Estimate | Serves the goal? | Owner (first) | Notes / risks |
|---|------|----------|------------------|---------------|---------------|
| 1 |      |          |                  |               |               |
| 2 |      |          |                  |               |               |
| 3 |      |          |                  |               |               |
|   | Total| ___      |                  |               |               |

Dependencies & risks: ___
Parking lot (raised, not solved here): ___

## Commitment check
Does the whole team believe we can finish the selected work and meet the goal?
[ ] Yes   [ ] Not yet — cut scope

That is the whole thing. Resist adding fields. Every box that does not change a decision is a box someone fills in out of habit and no one reads.

How to use it

The order of the fields is the order of the meeting, and it is deliberate.

1. Capacity before scope. Fill in capacity first so selection has a hard limit. Teams that leave capacity blank until the end always overcommit — the pile of tickets sets the number instead of the calendar. Work out the honest figure using velocity and capacity planning.
2. Goal before items. Write the sprint goal before pulling work, then use it as the test for every candidate item. The “serves the goal?” column is not decoration — an item that earns a “no” is a candidate to cut when the total runs over.
3. Pull until the total hits capacity, then stop. Watch the estimate total against your capacity number. When they meet, selection is done. If you are unsure how to size items, that is estimation, and it belongs in refinement — planning poker is a fast way to reach a shared number.
4. Make the commitment check real. The last box is the one people skip, and it is the most valuable. A soft “yes” now is a missed sprint later. If the room hesitates, cut scope until they mean it.

Fill it in live, not after

A template completed after the meeting is a record. A template filled in during the meeting is a plan — it forces the decisions to happen out loud, in front of the people who have to deliver them. If the capacity box is still empty at item selection, the meeting knows it has skipped a step.

This is also why a shared, editable surface beats a private doc for remote teams: everyone watches the total tick up against capacity in real time, so overcommitment is visible the moment it happens rather than discovered when the plan is read back.

When a template turns into a tool

A document is the right place to start, and for a small co-located team it may be all you ever need. You outgrow it at a predictable point: when keeping the template, the estimates, the capacity, and the board in sync by hand becomes its own chore. At that point a purpose-built tool stops being overhead and starts saving time — estimates flow from planning poker into the plan, capacity is tracked per person, and the sprint backlog is the board, not a copy of it. The sprint planning tools chapter covers what to look for and where the honest limits are.

Whichever you use, the four fields do not change: goal, capacity, selection, commitment. Get those written down every sprint and most planning problems never form.

Frequently asked questions

What should a sprint planning template include?

Four things at minimum: the sprint goal in one sentence, the team’s real capacity for the sprint, the selected backlog items with their estimates, and a commitment check. Everything else — attendees, dates, risks, parking lot — is useful but optional. If a field is not going to change a decision, cut it.

How do you fill in a sprint planning template?

Work top to bottom in the order you run the meeting: capacity first so scope has a limit, then the goal, then pull items until the estimate total reaches capacity, then confirm the team believes it. Fill it in live during planning, not afterwards — a template completed after the meeting is a record, not a plan.

Do you need a tool for sprint planning, or is a template enough?

A shared document is enough to start and beats no structure at all. A tool earns its place once you want estimates, capacity, and the board to stay in sync automatically, or when planning is remote and you need everyone editing at once. Start with the template; adopt a tool when the copying-between-places tax gets annoying.