Sprint planning is where the team decides what to build next. Here is how to run it well, from backlog preparation to capacity planning.
What is sprint planning?
Sprint planning is the first event of every sprint in the Scrum framework. During this meeting, the Scrum team answers two questions:
- What can we deliver in this sprint?
- How will we deliver it?
The output is a sprint backlog: a set of user stories the team commits to completing, along with a plan for delivering them.
Who attends?
- Product Owner: presents the prioritized backlog items and answers questions about scope and acceptance criteria.
- Development team: selects how many stories they can commit to based on their capacity and past velocity.
- Scrum Master: facilitates the meeting, keeps the timebox, and removes impediments.
All three roles are essential. A sprint planning without the Product Owner leads to scope misunderstandings. A sprint planning without the full development team leads to unrealistic commitments.
Before the meeting: preparation matters
Sprint planning is only as good as the backlog that feeds it. The Product Owner should ensure:
- Stories are refined: acceptance criteria are written, dependencies are identified, and the team has seen the stories at least once (in a refinement session).
- Stories are prioritized: the top of the backlog reflects the current business priorities.
- Stories are estimated: ideally through a prior Planning Poker session or another estimation technique.
If more than 20% of the stories discussed in sprint planning are "new" to the team, your refinement process needs improvement.
The two parts of sprint planning
Part 1: What are we building?
The Product Owner presents the top-priority stories. For each one:
- The PO explains the business value and acceptance criteria.
- The team asks clarifying questions.
- The team decides whether the story is ready to enter the sprint.
- If the story was not previously estimated, the team estimates it using Planning Poker or another technique.
The team pulls stories into the sprint until they reach their capacity. Capacity is based on velocity: the average number of story points completed in recent sprints.
Part 2: How will we build it?
For each selected story, the team discusses:
- Technical approach: architecture decisions, API design, database changes.
- Task breakdown: splitting the story into concrete tasks (design, implement, test, review, deploy).
- Dependencies: external APIs, other teams, shared services.
- Risks: unknowns, technical debt, performance concerns.
This part does not need to be exhaustive. A high-level plan is sufficient. The team will refine the approach as they work.
Timeboxing
The Scrum Guide recommends a maximum of 8 hours for a one-month sprint. In practice:
| Sprint length | Sprint planning duration |
|---|---|
| 1 week | 1-2 hours |
| 2 weeks | 2-4 hours |
| 3 weeks | 3-6 hours |
| 4 weeks | 4-8 hours |
If your sprint planning consistently exceeds these limits, the most likely causes are:
- Insufficient backlog refinement beforehand
- Stories that are too large and need splitting
- Scope discussions that should happen in refinement, not planning
Capacity planning
The team's capacity determines how many story points they can pull into the sprint.
Using velocity
Velocity is the average number of story points completed per sprint over the last 3-5 sprints. For example:
- Sprint 1: 34 points
- Sprint 2: 28 points
- Sprint 3: 31 points
- Average velocity: ~31 points
The team should plan for approximately 31 points in the next sprint. Do not plan to the maximum velocity. Use the average or slightly below to account for variability.
Adjusting for availability
Reduce capacity when:
- Team members are on vacation or sick leave
- Public holidays fall within the sprint
- Team members are split across multiple projects
- The sprint includes planned technical debt or infrastructure work
A simple formula: if the team normally has 5 members and one is absent for half the sprint, reduce planned capacity by ~10%.
Where Planning Poker fits in
Planning Poker is most effective when used before sprint planning, during backlog refinement. This way:
- Stories arrive at sprint planning already estimated
- Sprint planning focuses on selection and planning, not estimation
- The session is shorter and more focused
If estimation was not done beforehand, include it in Part 1 of sprint planning. Use Planning Poker for stories the team has not seen before, and quick consensus for familiar work.
See our complete Planning Poker guide for the step-by-step process.
Sprint goal
Every sprint should have a sprint goal: a single sentence that describes what the sprint will achieve. The sprint goal:
- Gives the team a shared purpose beyond a list of tickets
- Helps prioritize when trade-offs are needed mid-sprint
- Provides a clear "done" signal for stakeholders
Example: "Users can reset their password via email" is a good sprint goal. "Complete tickets PROJ-123, PROJ-124, PROJ-125" is not.
Common mistakes
1. No refinement before planning
If the team discovers stories for the first time during sprint planning, the meeting will take twice as long and produce worse estimates. Run a weekly refinement session to prepare stories 1-2 sprints ahead.
2. Over-committing
Teams under pressure often plan for more than their velocity allows. This leads to incomplete sprints, eroded trust, and growing technical debt. Plan conservatively. Finishing early is better than carrying over unfinished work.
3. Ignoring technical debt
Every sprint should reserve 10-20% of capacity for technical debt, bug fixes, and operational work. If you plan 100% of your velocity on new features, quality will degrade over time.
4. The PO dictating the sprint content
The Product Owner prioritizes the backlog. The development team decides how much they can commit to. This balance is fundamental to Scrum. The PO should not push the team to take more than their velocity supports.
5. Skipping Part 2
Selecting stories without discussing the "how" leads to surprises mid-sprint. Even a brief 5-minute technical discussion per story reduces risk significantly.
Sprint planning checklist
Before the meeting:
- Backlog is refined and prioritized
- Top stories have acceptance criteria
- Stories are estimated (or plan to estimate during planning)
- Team availability is known for the sprint
During the meeting:
- Product Owner presents each story
- Team asks clarifying questions
- Team pulls stories up to capacity (velocity)
- Team discusses technical approach for selected stories
- Sprint goal is defined
- Sprint backlog is committed
After the meeting:
- Sprint backlog is visible to all (board, Jira, Trello)
- Sprint goal is communicated to stakeholders
- Team starts working
Try Planning Poker for your next sprint
Estimation is the foundation of good sprint planning. Create a free Planning Poker session with your team and start estimating in seconds. No sign-up required.
