Sprint Planning Template: Capacity, Goals and Commitments
By Sebastiaan Jansen · · 8 min read
A sprint planning template records three decisions: how much time the team actually has, which outcome the sprint is for, and which backlog items the team will start. Fill those in before anyone argues about story points. The point of the page is that the commitment still makes sense on day six.
Plans fall apart when capacity, the goal, and the backlog live in three different places. Keep those numbers together on one page, whether that's a doc, a spreadsheet, or the board you already plan from.
What a sprint planning template has to capture
The Scrum Guide treats Sprint Planning as the event where the team sets a Sprint Goal and selects the work for it. Write the result down so a new joiner can follow it without watching the recording. Keep the page to one sprint, in this order:
- Sprint name, dates, and the people in it.
- Capacity in hours or days, after leave, meetings, and support.
- One sprint goal, written as an outcome.
- The selected items, each with an owner and a size the team agreed on.
- The commitment: what "done" means, and what is explicitly out.
- Risks, dependencies, and the review date.
If a field doesn't change a decision in the room, drop it.
Capacity before scope
Capacity is the time left for sprint work, and it is always smaller than a full-time calendar. A developer in the office for 10 days might have 7 left after standups, support, reviews, and a holiday. A plan that assumes all 10 will fail.
Count people, not roles. If Sam is out for three days, Sam's row changes. If support usually eats a day a week, write that down as a standing tax. Show both the total you will plan against and the total you turned down.
One goal, then the items that serve it
Twelve unrelated tickets are a queue, not a sprint. Require one sentence before the item list. It should pass the same test you'd use to write a sprint goal: could someone who missed the meeting tell you on Thursday whether the sprint is on track?
Items that don't serve that sentence go back to the product backlog. The difference between the sprint backlog and the product backlog is where an item sits, so if it wasn't selected, it doesn't go in this template.
Sprint planning template: the fields, with a worked example
Copy the headings and replace the numbers. These figures come from a six-person product team on a two-week sprint. Treat them as an example, not a benchmark.
Header
| Field | Example |
|---|---|
| Sprint | Sprint 18, 6 Oct to 17 Oct |
| Facilitator | Priya |
| Planning timebox | 60 minutes |
| Review | 17 Oct, 15:00 |
| Team in this sprint | 4 engineers, 1 designer, 1 product manager |
Put the sprint name and the review date next to the goal.
Capacity sheet
| Person | Calendar days | Leave and holidays | Meetings and support | Days for sprint work |
|---|---|---|---|---|
| Alex | 10 | 0 | 2 | 8 |
| Ben | 10 | 2 | 2 | 6 |
| Chris | 10 | 0 | 3 | 7 |
| Dana | 10 | 0 | 2 | 8 |
| Ellis (design) | 10 | 1 | 2 | 7 |
| Product manager | 10 | 0 | 6 | 4 |
| Total | 60 | 3 | 17 | 40 |
The planning budget is forty days, about 29 of them for the four engineers. Plan delivery below that, because interrupts kept landing inside recent sprints. Use days, unless someone is split across two products and a day means something different in each.
Goal and commitment
Sprint goal: a new customer can invite a teammate and see that person's first project without asking support.
Commitment: the invite flow, the acceptance email, and the empty-project state are merged to main and checked on staging with two real accounts. Out of this sprint: billing changes, SSO, and the admin audit log.
The goal says why, and the commitment says what will be true at the review. A request that arrives on day three either swaps something out or waits.
Selected work
| Item | Serves the goal? | Owner | Size (days) | Notes |
|---|---|---|---|---|
| Invite link and expiry | Yes | Alex | 3 | Needs email sandbox by Wednesday |
| Acceptance page | Yes | Ben | 4 | Copy reviewed by product |
| Empty project state | Yes | Dana | 3 | Design already in the file |
| Staging check with two accounts | Yes | Chris | 2 | Needs a second test company |
| Fix the invite error from last review | Yes | Dana | 1 | Already reproduced |
| Support rota | No (tax) | Rotating | 4 | In capacity, not in the goal |
Selected delivery work comes to 13 days, plus a 4-day support tax. Against roughly 29 engineer days, that leaves room for review and one bad surprise. If delivery work creeps toward 28 days, cut something. If the team disagrees on a size by more than a day, vote once and record the number you'll plan against.
Risks and dependencies
- Email sandbox access is still with the platform vendor. Owner: Priya. Needed by Wednesday.
- Design for the empty state is final, with no open review.
- There is no database migration in this sprint. If one appears, stop and re-plan.
Every risk needs an owner and a date. Without them, it's just something to worry about.
Template sprint planning in the meeting
A template won't run the meeting for you, but it keeps the meeting from wandering. This order also fits a one-hour sprint planning agenda:
- Confirm who is here and fix the capacity rows. Ten minutes.
- Decide what from last sprint rolls over, returns to the product backlog, or gets dropped. Ten minutes.
- Propose one sprint goal and argue until the sentence is specific. Ten minutes.
- Pull items that serve the goal until the total approaches capacity, leaving slack. Twenty minutes.
- Read the commitment and the out list aloud, then write the risks. Ten minutes.
The sprint planning guide covers the event itself. The template is what you fill in while it runs.
Fill in capacity before anyone opens the backlog. Once tickets are on screen, people defend their favorites and round the hours until everything fits. Treat rollover as its own step, too. If you roll every miss forward, you hide a bad forecast; if you roll nothing forward, you throw away context. Show inherited items as a separate count.
Walk the product backlog from the top and stop when the next item would push selected days past the budget. If the goal and the top of the backlog disagree, fix one of them before you leave the room. An invite goal sitting on top of unrelated bugfixes means the template has already failed.
An agile sprint planning excel template, and when to leave it
An agile sprint planning excel template is a reasonable place to start. For a team planning every two weeks, one workbook with a capacity tab, a selected-work tab, and a goal cell is enough. The most useful part is a formula that flags when the total goes over capacity.
Spreadsheets get awkward when people keep their own copies, when the backlog lives in another tool, or when you want the last eight sprints beside this one. Starting a fresh file each sprint loses the capacity history, the rollover, and any record of whether the commitment matched the review.
Jira, Linear, Azure Boards, and similar tools can name a sprint and hold its issues. They won't write the goal, the capacity math, or the out list, so add those to the board you already use. When several teams share a quarter, the shared board only needs each team's goal, the dates, and the cross-team risks.
Freeze a copy of the commitment when planning ends, and treat later edits as scope changes. If you only keep the latest version, you can't tell a changed plan from a missed one.
How to judge the commitment after the sprint starts
The template is a forecast made with partial information. At the review, compare three numbers:
- Days committed versus days completed on the selected items.
- Items rolled in from last sprint versus items rolled out of this one.
- Whether the sprint goal was true at the review, even if a side task slipped.
Velocity only tells you whether this commitment is close to recent sprints. It doesn't prove the goal mattered, and it doesn't excuse ignoring leave. Read what velocity does and does not say before you write a points target, because "Match 42 points" teaches people to resize tickets.
Cycle time is the other check. If similar tickets usually take four days and the plan assumes two, the template is optimistic before the sprint even starts. Keeping the last few sprints in one place is how you spot a repeated miss.
A range is more honest than a single date. If the last ten similar tickets took between two and six days, don't plan as if every one takes two. Falrow forecasts sample that history with 2,000 Monte Carlo runs, shown next to cycle time percentiles and cumulative flow. Falrow cycles keep a schedule and require a review of what rolls forward. Moving a ticket into the next sprint without a note leaves the same gap as before.
On day three, reopen the page only for sick leave, a slipped dependency, or a production issue you can cost in days, and change the commitment in writing. Empty space on the board is not spare capacity.
At the review, ask which field was wrong: capacity, sizes, or the goal. Change that rule for next time. A template that never changes is just a form.
FAQ
What should a sprint planning template include?
Sprint dates, a capacity total after leave and support, one sprint goal, the selected items with owners and sizes, an explicit out list, and the risks that could break the commitment. Add the review date and the names of the people in the sprint. Leave out roadmap themes and any field nobody used last time.
How do you calculate capacity in a sprint planning template?
List each person, subtract leave and holidays, then subtract a realistic allowance for meetings and interrupt work. Add up what's left and plan below that total, with slack for surprises you already know about. Use days unless the team estimates in hours. Write the allowance down so the next sprint uses the same rule.
Is an Excel sprint planning template enough?
Yes, for one team that plans together and keeps a single shared file. Put capacity, the goal, and the selected work in that file, and freeze a copy when planning ends. Move off the spreadsheet when people start keeping their own copies, or when you need rollover and past commitments beside the current sprint without copying them over by hand.
How long should sprint planning take if we use a template?
For a two-week sprint, one hour is enough if the backlog is ordered and the capacity rows are drafted. The template only saves time if someone fills in the header and the known leave before the meeting. With a blank page, the hour goes on reconstructing facts and the commitment gets rushed.