Sprint Planning
The Scrum ceremony where your team commits to a shared goal and a realistic slice of work for the sprint ahead.
What Is Sprint Planning?
Sprint planning is the ceremony that kicks off every sprint. The team gathers to answer two fundamental questions: what will we deliver this sprint, and how will we do it? The output is a sprint goal and a sprint backlog — a set of items the team believes it can complete by the end of the timebox.
Scrum's framework places a time limit on the meeting. For a standard two-week sprint, the Scrum Guide recommends a maximum of eight hours. Most healthy teams finish in two to four hours. If you find your sprint planning sessions routinely running long, the usual culprits are stories that were not refined before the meeting, a sprint goal that was never agreed in advance, or a team that is over-committing and scrambling to justify it.
Done well, sprint planning energises the team. Everyone leaves knowing exactly what they are working on, why it matters, and how the pieces fit together. Done poorly, it is a tedious exercise in copying cards from the backlog to a sprint column while the facilitator counts story points and prays the numbers add up.
Who Participates
Scrum Master (Facilitator)
The Scrum Master facilitates the meeting but does not drive decisions about what goes into the sprint. Their job is to keep the conversation productive, guard the timebox, and help the team reach consensus without letting planning devolve into scope negotiation.
Product Owner
The Product Owner is responsible for presenting the items from the top of the backlog and explaining their business value. They clarify acceptance criteria, answer questions, and negotiate priority. Crucially, they must come prepared — vague stories with no acceptance criteria are a planning anti-pattern that costs the team significant time.
Development Team
The entire development team participates — designers, engineers, testers, and anyone else doing the work. Only the people doing the work can realistically assess what is achievable. Decisions made without the delivery team present tend to be wildly optimistic.
Stakeholders and managers are generally not present at sprint planning. Their input should flow through the Product Owner via the product backlog, not through live participation in the planning session.
Preparation: What Must Happen Before the Meeting
Sprint planning is only as good as the preparation that precedes it. Walking into sprint planning with an unrefined backlog is the single most common reason these meetings run over time and end in confusion.
Refined Backlog
The top items in the backlog should already have clear titles, descriptions, and acceptance criteria. Stories should be small enough to complete in a single sprint. This is handled during backlog refinement sessions, not at sprint planning.
Velocity Data
Know your team's recent velocity — the average story points completed per sprint over the last three to five sprints. This sets a realistic upper bound for how much to commit. Velocity is a planning tool, not a performance target.
Team Availability
Check who is out of the office, who has partial availability, and whether there are public holidays during the sprint. Capacity planning with a full-team assumption leads to over-commitment every time.
Sprint Goal Draft
The Product Owner should arrive with a proposed sprint goal in mind. The team refines and commits to it, but having a draft prevents the meeting from starting with a blank page.
Defining the Sprint Goal
The sprint goal is a single, concise statement that describes the purpose of the sprint. It provides the team with a North Star when they face difficult decisions mid-sprint — if a new task serves the sprint goal, it might be worth taking on; if it does not, it can wait.
A good sprint goal is outcome-oriented rather than task-oriented. “Implement the checkout flow” is a task. “Enable customers to complete a purchase without leaving the app” is a goal. The distinction matters because the team needs flexibility to adjust the approach if they encounter technical obstacles. An outcome-based goal gives that flexibility.
The sprint goal should be agreed by the whole team, not imposed by the Product Owner. If a team member does not understand or does not believe in the sprint goal, they will not make good trade-off decisions when the sprint gets difficult.
Sprint Goal Checklist
- ✓ Single sentence or short phrase
- ✓ Describes a business outcome, not a list of features
- ✓ Understood and agreed by every team member
- ✓ Achievable within the sprint timebox
- ✓ Measurable — you can tell at the end whether it was met
Selecting Stories and Capacity Planning
Once the sprint goal is established, the team works through the top of the backlog and pulls in stories that support it. This is where story point estimates matter. The team compares the total estimated effort of candidate stories against available capacity.
Capacity is not simply the number of people multiplied by sprint days. Account for recurring meetings, code reviews, on-call rotations, and the inevitable support requests. A rule of thumb is that developers are available for roughly six focused hours per eight-hour day, and planned work should consume around 70–80% of that to leave room for the unexpected.
If estimates are done in story points, compare the candidate stories' total against the team's historical velocity range, not just the average. Committing to the average every sprint leads to a 50% chance of not delivering — by definition. Most teams aim to commit to something near the lower end of their velocity range to build in a buffer.
Stories should be pulled into the sprint to serve the sprint goal. Items that do not serve the goal should be deferred unless there is a strong dependency reason to include them. Overloading a sprint with low-priority hygiene tasks alongside a critical goal is a recipe for not completing either.
Breaking Stories Into Tasks
The second half of sprint planning focuses on the how. For each story the team commits to, developers discuss and break it down into concrete technical tasks. These tasks are the actual work items that will be picked up during the sprint.
Tasks should be small enough to complete in roughly one day or less. If a task takes longer than that to estimate, it is a signal to break it down further. Small tasks create a more accurate burndown chart, make it easier to spot blockers early, and reduce the risk of one person sitting on a large chunk of work for the whole sprint.
Task breakdown does not need to be exhaustive at sprint planning — you cannot anticipate every step before you start. The goal is to have enough clarity that work can begin immediately on day one, and that no story is a black box that only one person understands.
Some teams skip task breakdown during sprint planning and rely on developers to break down stories as they pick them up. This works for mature teams with experienced members. Newer teams benefit from doing some task breakdown collectively — it surfaces misunderstandings about scope before they become mid-sprint surprises.
Common Sprint Planning Mistakes
Skipping Backlog Refinement
If stories are not refined before sprint planning, the meeting becomes a refinement session. The team ends up debating scope and writing acceptance criteria instead of planning. Keep these activities separate.
No Sprint Goal
A sprint without a goal is just a list of tasks. Without a goal, the team cannot prioritise when something goes wrong mid-sprint, and stakeholders have no simple way to understand what the team is focused on.
Over-Committing
Teams consistently over-commit when they plan to velocity average without accounting for interruptions. Build in a buffer. Missing the sprint goal repeatedly destroys team morale and erodes stakeholder trust faster than committing conservatively ever would.
Managers Dictating the Sprint
Sprint planning is a collaborative commitment by the team, not a task assignment meeting run by management. When the team does not choose the work, they do not own the commitment. Accountability evaporates.
Treating Estimates as Promises
Story point estimates are forecasts, not guarantees. Holding developers accountable for hitting point estimates turns estimation into sandbagging. The sprint goal is the commitment, not the individual story estimates.
Remote Sprint Planning Tips
Remote and hybrid teams can run just as effective sprint planning sessions as co-located ones, but they require more deliberate tooling and facilitation. Silence on a video call is very different from silence in a room — you cannot see who is confused or disengaged.
Use a shared digital board. Ensure everyone can see and interact with the backlog in real time. Participants watching a screen share without editing access are passengers, not contributors.
Timebox ruthlessly. Remote meetings fatigue faster. Keep each story discussion to a fixed timebox — two minutes for well-refined stories, five for complex ones. Anything needing longer discussion likely was not refined enough.
Use planning poker for estimates. Simultaneous vote reveal eliminates anchoring bias regardless of location. Tools like ScrumChamps let distributed teams vote on stories in real time without one person's answer influencing everyone else before they vote.
Circulate the sprint goal draft before the meeting. Async review of the proposed goal means the team arrives with questions ready. You spend meeting time confirming and refining, not reading for the first time.
Confirm the commitment out loud. At the end of the session, have each team member verbally confirm they are on board with the sprint goal and backlog. In a remote setting this extra step prevents silent disagreement from surfacing mid-sprint.
Ready to estimate your backlog?
Accurate story point estimates are the foundation of a successful sprint plan. Run a planning poker session with your team — free, instant, no account required.