Sprint planning is the event that opens each Scrum sprint: the team selects items from the ordered product backlog, forecasts how much work can be completed in the coming sprint, and creates a sprint goal and sprint backlog. In scrum, it is a timebox event — capped at eight hours for a one-month sprint (proportionally shorter for shorter sprints).
ken-schwaber and jeff-sutherland developed sprint planning as part of Scrum's empirical-process-control model. The scrum-guide specifies two parts: what can be delivered in the sprint, and how the selected work will be achieved.
Intellectual Contribution
Sprint planning's intellectual contribution is the operationalization of short-cycle commitment. In traditional project management, plans are made once at the start of a project and tracked against thereafter. In Scrum, the team commits to a short horizon — one to four weeks — based on current understanding of requirements and their own velocity. This resolves the chronic problem of long-range plans becoming disconnected from reality: each sprint planning event is a fresh commitment based on current information.
The practice embodies the iron-triangle inversion central to Agile: rather than fixing scope and estimating time, sprint planning fixes time (the sprint length) and negotiates scope (what fits in the sprint). This shifts the fundamental question from "when will we be done with X?" to "what is the most valuable thing we can deliver in the next two weeks?"
Sprint planning also creates the conditions for self-organizing-teams: the development team, not the product owner or management, determines how much work they can take on. This is a genuine transfer of planning authority from hierarchical to team-level decision-making.
Relationship to Other Events
Sprint planning requires a refined product backlog — the product owner must have ordered, estimated, and clarified backlog items before the event. This creates dependency on backlog refinement (sometimes called "backlog grooming"), which the scrum-guide treats as an ongoing activity rather than a discrete event.
The sprint goal produced in planning gives the sprint coherence: it answers "why are we doing this sprint?" rather than simply listing features. This connects to responding-to-change: if circumstances change mid-sprint, the sprint goal allows the team and product owner to renegotiate scope while preserving the sprint's purpose.
Related practices: daily-standup, sprint-review, retrospective, story-points, timeboxing.