Sprint planning has a reputation for being one of the most painful meetings in software development. Two hours of debating story points. Engineers staring at stories they have never seen. The PM scrambling to explain requirements on the fly.
It does not have to be this way. The best sprint planning sessions take 60 minutes and end with a clear, achievable plan that the entire team understands and believes in.
The secret is in the pre-work.
Table of Contents
What Sprint Planning Is For
Sprint planning has one purpose: decide what the team will work on during the upcoming sprint and ensure everyone understands the plan.
It answers two questions:
It is NOT for:
Who Should Attend
Required
Optional
Not Invited
The Pre-Work That Makes Planning Fast
Sprint planning should be a confirmation, not a conversation. If the team is seeing stories for the first time during planning, the meeting will take 3 hours and produce a weak plan.
For the PM (2-3 Days Before Planning)
For the Tech Lead (1-2 Days Before Planning)
For the Team (During Grooming, Before Planning)
Backlog grooming (also called backlog refinement) should happen 1-2 days before sprint planning. In grooming:
If grooming is done well, sprint planning becomes a 30-minute confirmation meeting.
The Sprint Planning Agenda
Here is a practical agenda for a 60-minute sprint planning session (2-week sprint):
Part 1: Context (10 minutes)
Part 2: Story Selection (30 minutes)
- "Do we understand what is being asked?"
- "Do we agree with the estimate?"
- "Can this fit in the sprint?"
Part 3: Task Breakdown (15 minutes)
Part 4: Confirmation (5 minutes)
Capacity Planning
Capacity planning determines how much work your team can realistically take on. Without it, sprint planning is guesswork.
The Simple Formula
Available Capacity = Team Size x Sprint Days x Focus FactorFocus Factor
Most teams operate at a 60-70% focus factor. That means in a 10-day sprint, each engineer has about 6-7 days of actual development time.
| Activity | % of Time |
|---|---|
| Sprint work (stories) | 60-70% |
| Meetings (standups, reviews, 1:1s) | 10-15% |
| Code reviews | 5-10% |
| Bug fixes and support | 5-10% |
| Email, Slack, context switching | 5-10% |
Example Capacity Calculation
Available = (4 x 10 - 2) x 0.65 = 38 x 0.65 = 24.7 person-daysIf your team uses story points, look at velocity — the average number of points completed in recent sprints. Velocity is a better predictor than theoretical capacity because it already accounts for the focus factor.
What to Do When Capacity Is Low
Estimation: Story Points, Hours, or T-Shirt Sizes
Estimation is one of the most debated topics in agile. Here are the three main approaches and when each works.
Story Points
A relative sizing scale (typically Fibonacci: 1, 2, 3, 5, 8, 13, 21). Points measure complexity and effort relative to a reference story, not absolute time.
How to use them:
Best for: Teams that want to track velocity over time and predict capacity for future sprints.
Pitfall: Story points become meaningless when management converts them to hours or uses them to compare teams. Two teams' "5-point story" can be completely different in absolute effort.
Read more in the story points glossary entry.
Hours
Direct time estimates. "This will take about 16 hours of work."
Best for: Teams that bill by the hour (agencies, consultancies), or teams where management requires time-based reporting.
Pitfall: Hours feel more precise than they are. Saying "16 hours" implies a confidence that rarely exists. Also, developers consistently underestimate — by 50-100% for unfamiliar work.
T-Shirt Sizes
XS, S, M, L, XL. A rough relative sizing that avoids the false precision of hours and the ceremony of Planning Poker.
Best for: Early-stage estimation, roadmap-level sizing, and teams that find story points too heavyweight.
Pitfall: Hard to use for sprint capacity planning since there is no numeric value to sum. Some teams map sizes to point ranges (S=1-2, M=3-5, L=8-13) to bridge this gap.
Which to Choose
| Factor | Story Points | Hours | T-Shirt Sizes |
|---|---|---|---|
| Precision | Medium | High (false) | Low |
| Speed | Medium | Fast | Fast |
| Velocity tracking | Yes | Yes | No |
| Team resistance | Low | Medium | Low |
| Management legibility | Medium | High | Low |
For most product teams, story points with Planning Poker is the best balance of speed, accuracy, and team buy-in.
Commitment vs Forecast
One of the biggest sources of sprint dysfunction is confusion about whether the sprint plan is a commitment or a forecast.
Commitment Model
The team promises to deliver everything in the sprint backlog. If they do not, something went wrong (bad estimation, unexpected work, or lack of discipline).
Problems with commitment:
Forecast Model
The team's best prediction of what they will deliver, based on historical velocity and current capacity. It is expected to be wrong sometimes — that is normal.
Benefits of forecast:
Which to Use
The Scrum Guide switched from "commitment" to "forecast" language in 2011 for good reason. Use the forecast model. It produces better estimates, healthier team dynamics, and more accurate long-term planning.
The sprint goal, however, IS a commitment. The specific stories may shift, but the team should aim to achieve the sprint goal.
Common Antipatterns
Antipattern 1: The PM Dictates the Sprint
The PM walks in with a pre-built sprint and tells the team what they are doing. Engineers have no input on estimates, feasibility, or sequencing.
Why it fails: Engineers disengage because they have no ownership. Estimates are unrealistic because the PM does not understand the technical complexity.
Fix: The PM sets the priority and the goal. The team decides how much they can take on and how they will build it.
Antipattern 2: Planning Without Grooming
The team sees stories for the first time during sprint planning. They spend 2 hours asking clarifying questions.
Why it fails: Planning becomes grooming. Engineers cannot estimate accurately. The meeting runs long and energy is depleted.
Fix: Hold grooming 1-2 days before planning. Stories should be understood, estimated, and ready before they enter planning.
Antipattern 3: Overcommitting
The team takes on 30% more work than their velocity suggests. Every sprint, they carry over stories to the next sprint.
Why it fails: Creates a cycle of missed targets, declining morale, and unreliable forecasts. Stakeholders lose trust in sprint commitments.
Fix: Use velocity as the hard cap. If your average velocity is 25 points, plan for 25 points — not 32 because "this sprint will be different."
Antipattern 4: Story Point Debates
Two engineers spend 15 minutes debating whether a story is a 5 or an 8. The rest of the team checks Slack.
Why it fails: The difference between a 5 and an 8 is rarely meaningful. The estimate is already imprecise — arguing about it wastes time.
Fix: If estimates differ by one Fibonacci step, take the higher number and move on. Save debate for estimates that differ by 2+ steps — that signals a genuine misunderstanding of scope.
Antipattern 5: No Sprint Goal
The sprint plan is just a list of unrelated stories pulled from the top of the backlog.
Why it fails: Without a unifying goal, the team cannot make trade-offs during the sprint. When unexpected work arrives, they do not know what to cut.
Fix: Every sprint needs a one-sentence goal that describes the intended outcome. "Deliver the self-serve onboarding flow so new users can set up without a sales call."
Antipattern 6: The Infinite Sprint
Stories are never considered "done." They get partially completed, carry over to the next sprint, and grow scope.
Why it fails: Velocity becomes meaningless. The team never gets the satisfaction of completing work. Definition of Done is either unclear or not enforced.
Fix: Define done clearly before the sprint starts. If a story is not done by sprint end, it goes back to the backlog as a new item, not a carry-over.
A Sprint Planning Checklist
Use this checklist before and during sprint planning. For a printable version you can bring to each session, see the Sprint Planning Template.