Sprint planning
sprint PLAN-ing
A meeting where the team selects which work to complete in the upcoming sprint and plans how to accomplish it.
Sprint planning is the meeting where the team decides what to work on for the next sprint (usually 1-2 weeks). The PM presents prioritized user stories. The team discusses scope, asks questions, and commits to what they can realistically finish.
The goal is a sprint with a clear scope and a reasonable chance of success. Overcommitting leads to incomplete work and demoralized teams. Undercommitting wastes capacity. The sweet spot comes from experience and honest estimation.
Sprint planning works best when the stories are well-defined before the meeting. If the team spends the entire meeting clarifying requirements, there is a preparation problem. Stories should be refined and estimated in advance using story points so planning focuses on selection and sequencing.
Examples
A team runs sprint planning for a two-week sprint.
The PM presents 15 prioritized stories. The team estimates each using story points. Their velocity is 30 points per sprint. They select 12 stories totaling 28 points, leaving a small buffer for unexpected work.
A sprint planning meeting surfaces a dependency.
The team wants to build the notification feature but realizes it depends on an API endpoint that another team has not built yet. They move that story to the next sprint and pull in a different story instead.
A remote team runs async sprint planning.
Stories are pre-estimated in Linear. The PM writes a sprint proposal document. Team members comment async. A 30-minute sync call resolves open questions and finalizes the sprint scope.
Frequently asked questions
How long should sprint planning take?
For a two-week sprint, 1-2 hours maximum. If it takes longer, stories are not well-enough defined before the meeting. Pre-refinement (discussing and estimating stories before planning) keeps the planning meeting short and focused.
Who attends sprint planning?
The entire development team, the product manager, and the designer. Stakeholders are optional. The meeting is for the people who will do the work to agree on what work to do.
Related terms
An Agile framework that organizes work into fixed-length sprints with defined roles, ceremonies, and artifacts.
A software development methodology that delivers work in short iterations with continuous feedback and adaptation.
A short, plain-language description of a feature from the perspective of the user who wants it.
A large body of work that can be broken into smaller user stories, representing a significant feature or initiative.
A team meeting at the end of a sprint or project where members discuss what went well, what went wrong, and what to improve.
Want the complete playbook?
Picks and Shovels is the definitive guide to developer marketing. Amazon #1 bestseller with practical strategies from 30 years of marketing to developers.