sprint planning template
A sprint plan is not a Jira board screenshot. It is a contract between the PM and the engineering team about what will ship, what might ship, and what is blocking progress. If your sprint plan lives only inside your project management tool, nobody reads it. A written plan forces clarity.
The mistake most teams make: they plan the work but skip the goal. A sprint without a goal is a to-do list. When things go sideways mid-sprint — and they will — the goal is what tells you which items to protect and which to drop. Without it, every task feels equally important, and the team scrambles instead of making clean cuts.
Copy the markdown below. Paste it into Notion, Confluence, or a plain doc. Fill it out with your team before sprint start.
The template
Copy everything between the horizontal rules below.
# Sprint Plan: Sprint [number]
**Dates:** [start date] — [end date]
**Team:** [squad or team name]
**PM:** [name]
**Engineering Lead:** [name]
**Sprint Goal:** [One sentence — what does success look like at the end of this sprint?]
---
## Committed Items
Items the team commits to completing by sprint end.
| # | Item | Owner | Estimate | Acceptance Criteria | Status |
|---|------|-------|----------|-------------------|--------|
| 1 | [Feature/task name] | [Name] | [story points or days] | [What "done" means, specifically] | Not started |
| 2 | [Feature/task name] | [Name] | [story points or days] | [What "done" means, specifically] | Not started |
| 3 | [Feature/task name] | [Name] | [story points or days] | [What "done" means, specifically] | Not started |
**Total committed:** [X points / Y days]
---
## Stretch Items
Nice-to-haves if committed work finishes early. Do not start these until all committed items are on track.
| # | Item | Owner | Estimate | Notes |
|---|------|-------|----------|-------|
| 1 | [Feature/task name] | [Name] | [estimate] | [Why this is stretch, not committed] |
| 2 | [Feature/task name] | [Name] | [estimate] | [Why this is stretch, not committed] |
---
## Carry-Over from Last Sprint
Items that did not complete in Sprint [N-1]. Every carry-over needs a reason — if the same item carries over twice, it needs a different plan.
| Item | Original Sprint | Reason Incomplete | Plan This Sprint |
|------|----------------|-------------------|-----------------|
| [Feature/task name] | Sprint [N-1] | [Why it slipped — be specific] | [What changes this time] |
---
## Dependencies and Blockers
| Dependency/Blocker | Affects Which Item | Owner of Resolution | Expected Resolution Date | Status |
|-------------------|-------------------|-------------------|------------------------|--------|
| [e.g., API from Platform team] | Item #2 | [Name] | [Date] | Pending |
| [e.g., Design review for checkout] | Item #3 | [Name] | [Date] | Resolved |
---
## Capacity Notes
| Team Member | Availability | Notes |
|-------------|-------------|-------|
| [Name] | [X out of Y days] | [Holiday / on-call / planned absence] |
| [Name] | [X out of Y days] | [Reason if reduced] |
**Team capacity this sprint:** [Total available person-days or points]
---
## Definition of Done
A committed item is "done" when all of these are true:
- [ ] Code merged to main branch
- [ ] Unit tests passing
- [ ] Acceptance criteria verified by PM or QA
- [ ] No P0/P1 bugs open against this item
- [ ] [Add any team-specific gates: design review, security review, etc.]How to use this
Before planning: Fill in capacity notes and carry-over items first. The team needs to know how much room they have before committing to anything.
During planning: Write the sprint goal together. If the team cannot agree on a single sentence, the sprint has too many unrelated items. Cut until the goal is crisp. Then fill committed items — each row needs an owner and acceptance criteria before it earns a spot.
During the sprint: Update status in committed items. When a blocker surfaces, add it to the dependencies table immediately — do not wait for standup. If a committed item is at risk, decide whether to descope or pull from stretch. The sprint goal tells you which call to make.
At sprint end: Any incomplete item moves to carry-over in the next sprint plan. Write the reason it slipped. If you cannot write the reason clearly, you did not understand the blocker.
Related pages
- Sprint Planning — how to run the planning meeting itself, common dysfunctions, and how to size work
- Writing PRDs — where acceptance criteria in the committed items table come from
- Agile for PMs — the PM’s role in agile ceremonies, and which ones actually matter