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 Scrum event that starts every sprint: the whole Scrum Team decides what it will work on and how. The Scrum Guide organizes it around three topics. Why is this sprint valuable? The team agrees on a sprint goal. What can be done in this sprint? The Developers select items from the top of the Product Backlog, using their past performance (their velocity) and their capacity for the coming sprint. How will the chosen work get done? The Developers break the items into smaller pieces of work, often tasks of a day or less. The sprint goal, the selected items and the plan together form the sprint backlog. The event is timeboxed to a maximum of eight hours for a one-month sprint, and is usually shorter for shorter sprints. It works best when the backlog has been refined and estimated beforehand, for example with Planning Poker, so that the meeting is about choosing and planning rather than discovering stories.
Who attends?
- Product Owner: presents the prioritized backlog items and answers questions about scope and acceptance criteria.
- Developers: select 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.
How do you prepare for sprint planning?
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.
What happens during sprint planning?
The sprint goal answers the "why" (see below). The "what" and the "how" are the two working parts of the meeting.
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.
How long should sprint planning take?
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
How much work should the team plan?
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. Our guide to sprint velocity covers the calculation, the difference with capacity and release forecasting.
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%.
When should the team estimate with Planning Poker?
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. Keep deadlines and opinions about size out of the discussion until everyone has voted: a number said too early anchors the whole team (see anchoring bias in estimation).
What makes a good 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.
What are the most common sprint planning 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
Frequently asked questions
How long should sprint planning be? Sprint planning is timeboxed to a maximum of eight hours for a one-month sprint, according to the Scrum Guide, and is usually shorter for shorter sprints. In practice, many teams with two-week sprints need two to four hours. If planning keeps running over, the backlog probably needs more refinement before the meeting.
Who attends sprint planning? The whole Scrum Team attends sprint planning: the Product Owner, who brings the ordered backlog and the business context, the Developers, who select the work and plan how to do it, and the Scrum Master, who facilitates. The team may also invite other people, such as experts or stakeholders, to give advice.
What is the output of sprint planning? The output of sprint planning is the sprint backlog. According to the Scrum Guide, it combines three elements: the sprint goal, the Product Backlog items selected for the sprint, and the Developers' plan for delivering them. The sprint goal is the only commitment; the plan can evolve as the team learns during the sprint.
Can the sprint backlog change during the sprint? Yes, the sprint backlog can change during the sprint. The Developers update it as they learn more, and scope can be clarified or renegotiated with the Product Owner. The limit is the sprint goal: no change should endanger it. If the goal itself becomes obsolete, only the Product Owner can cancel the sprint.
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.
