Product

Sprint Planning Template

Sprint planning goes wrong in two places: the team commits to last sprint's velocity with this sprint's people, and unfinished work rolls over without anyone deciding it should. This template does the capacity math in the open, makes a decision on every carried-over item, and ends with a sprint goal someone could check on demo day.

Updated 2026-10-27

Copy and adapt

The template

Sprint planningTemplate

Sprint [N] planning, [Team], {{date}}

Sprint: [start date] to [end date], [10] working days Product owner: [name] Facilitator: [name] Related: [[Roadmap]]

Last sprint in one line

Committed [X] points, finished [Y]. Velocity, last three sprints: [a, b, c]

Sprint goal

[One sentence. What will be true at the sprint review that is not true today?] We will know we met it when: [a check anyone can run]

Capacity

[Name]: [8] of [10] days ([leave, on-call, interviews])
[Name]: [10] of [10] days
Total: [n] person-days. Minus [20] percent for meetings, reviews and support: [n] focus days
Planned load: [n] points ([average velocity] scaled to this sprint's capacity)

Carried over (decide each one)

[Item] ([old estimate]): [finish this sprint, re-estimated to n / split / back to backlog]. Why it did not finish: [reason]

Sprint backlog

[Story] ([points]) (@[owner]) Serves goal: [yes]
[Story] ([points]) (@[owner]) Serves goal: [yes]
[Bug or tech debt] ([points]) (@[owner])

Stretch (only once the goal is safe)

[Story] ([points])

Definition of done

[Code reviewed, tests pass, deployed to staging, product owner accepted, docs updated]

Risks and dependencies

[Risk] (watch: [name])

Scope-change rule

[New work mid-sprint swaps out an item of equal size, agreed by product owner and team]

Backlog for next sprint

[Item] ([estimate]) Ready: [yes / needs design / needs answer from name]

5 examples

Examples for different situations

The same structure, filled in for the situations people actually bring to it. Copy the one closest to yours.

1.Standard two-week sprint for a product squad

When it fits: Use this when the team is settled, velocity is stable, and the job of planning is to pick a goal tight enough that the sprint review has a clear yes or no.

Standard two-week sprint for a product squadExample 1

Sprint 42 planning, Checkout squad, 2026-11-02

Sprint: 2026-11-02 to 2026-11-13, 10 working days Product owner: Hana Facilitator: Leo Related: [[Q4 roadmap]]

Last sprint in one line

Committed 31 points, finished 29. Velocity, last three sprints: 28, 30, 29

Sprint goal

Guest checkout works end to end on web: a shopper without an account can pay and receive a receipt email. We will know we met it when: Hana completes a guest purchase on staging with a test card and gets the receipt.

Capacity

Leo: 10 of 10 days
Carmen: 10 of 10 days
Yusuf: 8 of 10 days (on-call Nov 9 and 10)
Ade: 9 of 10 days (conference talk Nov 12)
Total: 37 person-days. Minus 20 percent: about 30 focus days
Planned load: 29 points

Carried over (decide each one)

Saved-address autocomplete (3): finish this sprint, still 3. Blocked on the address API key until Friday; now unblocked.

Sprint backlog

Guest checkout form and validation (5) (@Carmen) Serves goal: yes
Payment intent without a customer record (8) (@Leo) Serves goal: yes
Receipt email for guest orders (3) (@Ade) Serves goal: yes
Convert guest to account after purchase (5) (@Carmen) Serves goal: yes
Saved-address autocomplete (3) (@Yusuf)
Fix double-submit on slow connections (2) (@Yusuf)
Remove the old cart service flag (3) (@Leo)

Stretch (only once the goal is safe)

Guest order lookup by email (3)

Definition of done

Reviewed, tests pass, on staging, Hana accepted, analytics event fires

Risks and dependencies

Payment provider sandbox has been slow this month (watch: Leo). If it is down for a day, the receipt email still ships against a mock.

Scope-change rule

Anything new swaps out an item of equal size. Hana decides what goes.

Backlog for next sprint

Guest checkout on iOS (8) Ready: needs design from Bea
Apple Pay for guests (5) Ready: yes

2.Holiday-week sprint with reduced capacity

When it fits: Use this when a holiday and leave cut the team's days by a third, the product owner still wants the full feature, and the plan has to show the math before anyone commits.

Holiday-week sprint with reduced capacityExample 2

Sprint 23 planning, Growth team, 2026-11-16

Sprint: 2026-11-16 to 2026-11-27, 9 working days (Thanksgiving Nov 26; most of the team also off Nov 27) Product owner: Marcus Facilitator: Dee Related: [[Referral program]]

Last sprint in one line

Committed 24 points, finished 24. Velocity, last three sprints: 22, 25, 24

Sprint goal

Referral links are live for 10 percent of users and we can count sign-ups that came from them. We will know we met it when: the referral dashboard shows at least one attributed sign-up from production.

Capacity

Dee: 7 of 9 days (off Nov 25 and 27)
Sven: 8 of 9 days (off Nov 27)
Rosa: 4 of 9 days (leave Nov 16 to 20)
Kai: 8 of 9 days (off Nov 27)
Total: 27 person-days, against 40 in a normal sprint. Minus 20 percent: about 22 focus days
Planned load: 16 points (average 24, scaled by 27 / 40 and rounded down)

Carried over (decide each one)

None.

Sprint backlog

Generate and store referral codes (3) (@Sven) Serves goal: yes
Referral link on the account page behind a 10 percent flag (5) (@Kai) Serves goal: yes
Attribute sign-ups to referral codes (5) (@Dee) Serves goal: yes
Referral dashboard tile (3) (@Rosa) Serves goal: yes

Not this sprint (agreed with Marcus)

Reward credits for the referrer (8). Marcus wanted them in. The team showed the capacity line; Marcus agreed to launch links first and add rewards in Sprint 24. Risk he raised: referrers without a reward may not share. We will see that in the numbers either way.

Definition of done

Reviewed, tests pass, deployed behind the flag, Marcus accepted

Risks and dependencies

Nobody deploys Nov 25 to 27 (watch: Dee). Everything ships by Nov 24 or waits.

Scope-change rule

No additions this sprint. Requests go to the Sprint 24 backlog.

Backlog for next sprint

Reward credits for the referrer (8) Ready: needs finance sign-off on credit value
Referral link in the post-purchase email (3) Ready: yes

3.First sprint of a new team with no velocity

When it fits: Use this when the team was formed last week, nobody knows how fast it works yet, and the real output of the first sprint is a baseline and a working agreement.

First sprint of a new team with no velocityExample 3

Sprint 1 planning, Data platform team, 2026-11-09

Sprint: 2026-11-09 to 2026-11-20, 10 working days Product owner: Ingrid Facilitator: Tariq (rotating from Sprint 2) Related: [[Data platform charter]]

Last sprint in one line

First sprint. No velocity yet. We will estimate in points anyway and compare after.

Sprint goal

The nightly orders export runs on the new pipeline in parallel with the old one, and the row counts match. We will know we met it when: three consecutive nights show matching row counts in the comparison report.

Capacity

Tariq: 10 of 10 days
Mei: 10 of 10 days
Bruno: 6 of 10 days (still handing over his old team's on-call until Nov 16)
Total: 26 person-days. Minus 30 percent, not 20, because setup and onboarding will eat more than usual: about 18 focus days
Planned load: no velocity, so we committed by asking each person whether their items fit in their days. They did with two days to spare.

Carried over (decide each one)

None.

Sprint backlog

Pipeline repo, CI and staging environment (3) (@Tariq) Serves goal: yes
Orders extract job on the new pipeline (5) (@Mei) Serves goal: yes
Row-count comparison report (3) (@Bruno) Serves goal: yes
Alert when the nightly job fails (2) (@Tariq) Serves goal: yes

Working agreements (draft, revisit at the retro)

Pull requests reviewed within one working day
Standup at 09:45, 15 minutes, async on Fridays
Estimates in points, re-estimated only at planning

Definition of done

Reviewed, tests pass, runs on staging for one night without errors, Ingrid accepted

Risks and dependencies

Read access to the orders replica is still pending with the DBA team (watch: Ingrid). Without it, nothing in the goal can start.

Scope-change rule

Ingrid is the only person who can add work. Requests from other teams go through her.

Backlog for next sprint

Move the customers export (5) Ready: needs schema answer from Mei
Decommission the old orders cron (2) Ready: only after three matching weeks

4.Planning after a missed sprint

When it fits: Use this when the last sprint finished barely half of what was committed, the product owner and the engineering manager disagree about why, and the next plan has to fix the cause rather than just commit less.

Planning after a missed sprintExample 4

Sprint 18 planning, Mobile team, 2026-11-30

Sprint: 2026-11-30 to 2026-12-11, 10 working days Product owner: Nora Facilitator: Pablo (EM) Related: [[Mobile app 4.1]]

Last sprint in one line

Committed 34 points, finished 19. Velocity, last three sprints: 30, 31, 19

What happened (from the Sprint 17 retro)

About 30 percent of the team's time went to support escalations after the 4.0 release. None of it was planned.
Nora's view: the team over-committed. Pablo's view: the commitment was fine; the support load was invisible. Both partly right. Agreed: plan support time explicitly, and stop counting it as an interruption.

Sprint goal

Offline drafts sync without data loss on iOS and Android. We will know we met it when: the 12 sync conflict test cases pass on both platforms and QA signs off.

Capacity

Five engineers, 48 person-days (Ola out Dec 10 and 11)
Support rotation: one engineer per week on escalations, about 9 days in total
Minus 20 percent of the rest for overhead: about 31 focus days
Planned load: 21 points. Lower than average on purpose, because last sprint's 19 was the honest number.

Carried over (decide each one)

Offline draft sync, iOS (8): finish this sprint, re-estimated to 5. Most of the work is done; conflict handling is left.
Offline draft sync, Android (8): finish this sprint, stays at 8. Not started.
Settings screen redesign (5): back to the backlog. It does not serve the goal and was never started.
Push notification grouping (3): split. The server part (2) is done and ships; the client part goes to the backlog.

Sprint backlog

Offline draft sync, iOS conflict handling (5) (@Ola) Serves goal: yes
Offline draft sync, Android (8) (@Femi) Serves goal: yes
Sync conflict test suite on CI (3) (@Jae) Serves goal: yes
Top three crash fixes from the 4.0 release (5) (@Rin)
Support rotation (@Jae week 1, @Femi week 2)

Definition of done

Reviewed, tests pass, in TestFlight and Play internal testing, QA signed off

Risks and dependencies

If escalations exceed one person's week, the crash fixes move out first, not the goal (watch: Pablo).

Scope-change rule

New escalations go to the support engineer. If they need a second person, Nora and Pablo decide together what leaves the sprint.

Backlog for next sprint

Settings screen redesign (5) Ready: yes
Push notification grouping, client (2) Ready: yes

5.Client project sprint with a mid-sprint change request

When it fits: Use this when you are an agency or contractor, the client pays per sprint, and a request lands halfway through that has to be traded against something already promised.

Client project sprint with a mid-sprint change requestExample 5

Sprint 3 of 6 planning, Halden Outdoor website, 2026-11-16

Sprint: 2026-11-16 to 2026-11-27, 9 working days (Thanksgiving Nov 26) Product owner: Erik Halden (client) Facilitator: Simone (agency PM) Related: [[Halden Outdoor]]

Last sprint in one line

Committed 20 points, finished 20. Velocity, two sprints: 18, 20

Sprint goal

Shoppers can filter the product catalog by activity and size, and every product page shows live stock from the warehouse system. We will know we met it when: Erik filters to "hiking, size M" on staging and every result shows a stock count that matches the warehouse.

Capacity

Simone: 4 of 9 days (shared with another client)
Joaquín: 9 of 9 days
Lina: 8 of 9 days
Total: 21 person-days. Minus 20 percent: about 17 focus days
Planned load: 17 points

Carried over (decide each one)

None.

Sprint backlog

Activity and size filters (5) (@Joaquín) Serves goal: yes
Warehouse stock sync every 15 minutes (8) (@Lina) Serves goal: yes
Out-of-stock badge and hidden add-to-cart (2) (@Joaquín) Serves goal: yes
Image compression on upload (2) (@Lina)

Definition of done

Reviewed, on staging, Erik accepted on the Friday demo call

Scope-change rule (from the contract)

New work during a sprint replaces work of equal size, chosen by the client. Anything larger is quoted for the next sprint.

Change during the sprint

2026-11-20: Erik asked for a holiday gift guide page before Black Friday (estimated 3). Simone offered the swap. Erik chose to drop image compression (2) and accept that the guide ships with a simpler layout. Agreed in writing on the call; recap email sent the same day.

Backlog for next sprint

Image compression on upload (2) Ready: yes
Size guide modal (3) Ready: needs size charts from Erik
Checkout address validation (5) Ready: yes

What a sprint plan has to settle

Sprint planning answers three questions, and the meeting is not over until all three have a written answer:

Why this sprint? The sprint goal: one outcome the team will show at the review.
What fits? Capacity for these people on these days, and the items that fit inside it.
How will we know it is done? A definition of done that applies to every item, and a check for the goal itself.

Everything else in the template supports one of those. The carried-over section stops unfinished work from inflating the plan. The scope-change rule protects the goal once the sprint starts. The backlog for next sprint makes the next meeting shorter.

Writing a sprint goal that can fail

Most sprint goals are a list with a verb in front: "work on checkout improvements". Nobody can tell at the review whether it happened. A useful goal names something that will be true at the end that is not true now, and a way to check it: "a shopper without an account can pay and receive a receipt email; the product owner completes a guest purchase on staging."

A goal like that can fail, which is what makes it useful. When the sprint gets squeezed, the team knows which items protect the goal and which can move.

Capacity, honestly

Velocity is a description of the past, measured with a specific set of people and days. Carrying it forward unchanged into a sprint with a holiday, two people on leave and an on-call rotation is how teams commit to 30 points and finish 19.

Do the math in the plan where everyone can see it. Available days per person, a deduction for overhead (20 percent for an established team, more for a new one), then velocity scaled to the result. It takes three minutes and removes most of the arguments about how much fits.

Carryover without drift

Unfinished items are information. Each one gets a decision: finish it with a fresh estimate, split it so the finished part ships, or send it back to the backlog where it competes with everything else. The fourth example shows all three in one sprint. What should never happen is an item quietly appearing in the next sprint with its old estimate, because that hides both the real velocity and the real priority.

Keeping the backlog ready

The quickest way to shorten sprint planning is to arrive with the top of the backlog already refined: about two sprints' worth of items that are clear, estimated and unblocked. A simple backlog template is enough:

## Backlog, [Team], refined [date]
- [Item]: [why it matters, one line] ([estimate]) Ready: [yes / needs X from name]

Hold a 30-minute refinement session mid-sprint. Anything marked "needs X from name" becomes that person's action, so by planning day it is ready or visibly not.

Common mistakes

Planning to last sprint's velocity. Scale it to this sprint's capacity.
A goal that is a list. If it cannot fail, it is not a goal.
Silent carryover. Decide each item, every time.
Interruptions treated as surprises. If they happen every sprint, plan them.
Refining in the planning meeting. Planning a backlog that is not ready takes three hours and produces guesses.

For the meeting that closes the sprint, use the sprint retrospective template. For daily check-ins during it, the standup meeting template keeps the goal in front of the team.

Customization tips

Write the goal before picking stories
Pick the sprint goal first, then pull the stories that serve it. If you pick stories first, the goal becomes a summary of a list, and summaries cannot fail. A goal that cannot fail tells the sprint review nothing.
Scale velocity by capacity, not by hope
Take the average of the last three sprints and multiply it by this sprint's person-days divided by a normal sprint's. The holiday example shows the arithmetic in one line. It ends most arguments about how much fits.
Decide every carried-over item out loud
Each unfinished item gets one of three decisions: finish it (with a fresh estimate), split it, or send it back to the backlog. Work that rolls over silently is how a team ends up carrying the same ticket for five sprints.
Plan support and on-call as work
If interruptions regularly take a quarter of the sprint, put them in the plan as a rotation with days attached. It is the same amount of work. The difference is that the commitment stops being wrong before the sprint starts.
Keep the scope-change rule visible
Write the rule in the plan, not just in team lore. When the request arrives on day six, the conversation is about which item to swap, not whether swapping is allowed.
Shorter sprints need shorter plans
For a one-week sprint, drop the stretch and risks sections and keep goal, capacity, backlog and carried over. Planning should take about an hour per week of sprint, and less once the backlog is kept ready.

In the app

How to do this in Scribelet

Open Desk Settings, then Templates, tap Add Template, paste the sprint planning template and set the category to Planning. Keep {{date}} in the title so each sprint's note is dated when you create it.
Write sprint backlog items as - [ ] Receipt email for guest orders (@Ade) @due(2026-11-13). They show up in the Tasks view and on your daily note until ticked.
Link every sprint note to the roadmap with [[Q4 roadmap]]. The roadmap note's backlinks panel then lists every sprint that served it, which is a quick way to see whether the plan matched the priorities.
Before planning, ask the AI chat "what got carried over in the last three sprints and why?" It answers from your sprint notes with citations, so the pattern is on screen before anyone estimates.
Tag every sprint note #sprint so all your plans sit under one tag, and open the last one before planning to copy its Backlog for next sprint into the new note.

Templates, template variables and AI generation are documented in Note templates.

Frequently asked questions

What should a sprint planning template include?

A sprint goal, the team's capacity for this sprint, the backlog items pulled in with estimates and owners, a decision on anything carried over, and a definition of done. The template above also adds a scope-change rule and a refined backlog for the next sprint, which keep the following planning short.

How long should sprint planning take?

The Scrum Guide caps it at eight hours for a one-month sprint, which scales to about four hours for two weeks. Teams with a refined backlog usually need 60 to 90 minutes for a two-week sprint. If planning runs long every time, the backlog was not ready, and the fix is refinement before the meeting.

How do you calculate sprint capacity?

Count each person's available days after leave, holidays, on-call and known commitments. Subtract 20 to 30 percent for meetings, code review and support. Then scale your average velocity by this sprint's available days over a normal sprint's. The holiday example above shows it worked through.

What is a backlog template?

A backlog template is a consistent format for items waiting to be worked on: what it is, why it matters, an estimate, and whether it is ready to plan. The format at the end of this page works as a backlog template on its own, and the last section of the sprint planning template uses it for the next sprint.

Is there a sprint planning template for Excel?

Spreadsheets handle the capacity math well and are common for that reason. They are weaker at the parts that matter in the meeting: the goal, the reasons behind carried-over decisions, and the scope-change agreement. A text note for the plan, with a small capacity list, keeps both in one place.

Sprint plans that remember the last sprint

Keep each sprint plan in Scribelet, track every backlog item as a task with an owner and a due date, and ask your notes what keeps getting carried over before the next planning starts. Free to start.

Plan your next sprint

or get the app

Download on theApp Store

Free plan, no credit card. See pricing

Meetings

Sprint Retrospective Template

A retrospective is only as good as what changes afterwards. This template opens by checking whether last retro's actions worked, grounds the discussion in sprint facts, and ends with at most two actions, each with an owner, a date and a sign that it worked.

Meetings

Standup Meeting Template

Blockers first, one line per person for done and next, and a parking lot for everything that needs more than thirty seconds. This daily standup template also tracks how many days each blocker has been open, which is the number most standups never write down.

Product

Product Roadmap Template

A roadmap is a promise about priorities, not a schedule. This template ties every initiative to a goal, says how confident you are in each date, keeps a visible list of what you are not doing, and logs every change with its reason. Copy it as-is, or start from the roadmap example closest to your audience.

Product

User Story Template with Acceptance Criteria

The format is one line: As a [role], I want [capability] so that [outcome]. The line is the easy part. This template adds what makes a story buildable: Given/When/Then acceptance criteria, edge cases, what is out of scope, and an INVEST check before it enters a sprint.

Product

PRD Template (Product Requirements Document)

A PRD (product requirements document) says what problem a release solves, for whom, how you will know it worked, and what it deliberately will not do. This template keeps it short enough to be read, and adds what most PRD templates leave out: a status, a decision log, and open questions with owners and dates.

Article

Definition of done

From the Scribelet blog