Sprint Planning Template for Scrum Teams

Free Sprint Planning Template

Sprint planning is the ceremony where the team commits to what they will deliver in the upcoming sprint. A good sprint planning session produces a clear sprint goal, a realistic sprint backlog, and a shared understanding of the work.

---

Sprint Planning Template

Sprint Number: [e.g. Sprint 42]
Sprint Dates: [Start date] → [End date]
Sprint Duration: [ ] 1 week  [ ] 2 weeks  [ ] 3 weeks
Date of Meeting: [YYYY-MM-DD]
Facilitator: [Scrum Master name]
Attendees: [List of team members present]

---

## 1. Sprint Goal
[One or two sentences describing what the team will achieve this sprint and why it matters.]

Example: "Enable users to complete onboarding without support intervention by shipping the guided setup flow."

---

## 2. Team Capacity

| Team Member | Available Days | Capacity (pts/days) | Notes |
|---|---|---|---|
| [Name] | [e.g. 8/10] | [e.g. 16 pts] | [Holiday, meetings, etc.] |
| [Name] | | | |
| [Name] | | | |
| [Name] | | | |
| **Total** | | | |

**Yesterday's velocity (avg last 3 sprints):** [X story points]
**Target for this sprint:** [X story points]

---

## 3. Sprint Backlog

| # | Story / Task | Story Points | Owner | Notes |
|---|---|---|---|---|
| 1 | | | | |
| 2 | | | | |
| 3 | | | | |
| 4 | | | | |
| 5 | | | | |
| **Total** | | | | |

---

## 4. Dependencies & Risks

| Item | Dependency / Risk | Owner | Mitigation |
|---|---|---|---|
| | | | |
| | | | |

---

## 5. Definition of Done Checklist

Confirm the team's DoD applies to all stories in this sprint:

- [ ] Code reviewed by at least one peer
- [ ] Unit tests written and passing
- [ ] Acceptance criteria met and verified
- [ ] Deployed to staging environment
- [ ] Product Owner has accepted the story
- [ ] Documentation updated (if applicable)

---

## 6. Team Agreements for This Sprint

[Note any specific agreements the team has made for this sprint — pairing arrangements, code freeze dates, demo schedule, etc.]

---

## 7. Sprint Planning Outcome

**Sprint Goal confirmed:** [ ] Yes  [ ] No — needs revision

**Backlog committed:** [ ] Yes  [ ] Partially — [explain]

**Team confidence in plan (1–5):** [Average of team's score]

**Notes / parking lot:**

---

Sprint Planning Fields Explained

Sprint Goal

The sprint goal is the single most important output of sprint planning. It answers: "What are we trying to accomplish, and why does it matter?" A good sprint goal gives the team latitude to make technical decisions while keeping everyone aligned on the outcome.

A bad sprint goal is a list of tickets: "Complete tickets PROJ-123, PROJ-124, and PROJ-125." That is a sprint backlog, not a goal.

Capacity

Never plan to 100% capacity. Leave room for code review, support queries, unplanned bugs, and the inevitable meeting that overruns. Most experienced teams plan to 70–80% of theoretical maximum.

Use the Planning Poker tool to estimate stories with your whole team before locking in the sprint backlog.

Definition of Done

Agreeing on the Definition of Done before the sprint — not after — eliminates the end-of-sprint debate about whether a story is truly complete.

---

Sprint Planning Agenda (90 minutes for a 2-week sprint)

| Time | Activity | |---|---| | 0:00 – 0:10 | Review last sprint: velocity, carryover | | 0:10 – 0:20 | Confirm team capacity and availability | | 0:20 – 0:35 | Product Owner presents top backlog items | | 0:35 – 0:50 | Team estimates and discusses stories | | 0:50 – 1:10 | Select stories, define sprint backlog | | 1:10 – 1:20 | Define sprint goal | | 1:20 – 1:30 | Confirm DoD, identify risks, team confidence check |

---

Common Sprint Planning Mistakes

No sprint goal. A list of tickets is not a goal. Without a goal, the team has no guiding principle for making trade-offs when scope needs to change mid-sprint.

Planning to 100% capacity. Something always comes up. Teams that plan to full capacity carry work over every sprint and erode trust in their forecasts.

Skipping estimation. Adding unestimated stories to the sprint backlog makes capacity planning impossible. Estimate in planning or explicitly flag stories as unestimated risks.

Product Owner not present. Sprint planning without the PO produces a backlog the team will need to clarify item by item during the sprint. It's a false economy.

No discussion — just ticket assignment. Planning is not a ticket-shuffling exercise. The most valuable part is the conversation that surfaces hidden complexity and shared understanding.