Sprint planning: the ceremony that opens the sprint

Sprint planning is the ceremony that opens the sprint. The team agrees what it will deliver and sketches how — turning a slice of the product backlog into a sprint backlog and a single, clear sprint goal. Done well it takes a few hours and buys the team two weeks of focus. Done badly it’s a queue-filling exercise the team spends the rest of the sprint quietly renegotiating.

This chapter is the ceremony-level summary. For the full run of show — the agenda, the roles, the capacity maths, and worked sprint-goal examples — see the complete guide to sprint planning.

Where planning sits in the cycle

Sprint planning is the first of the agile ceremonies, and its output is the reference point for every other one. The daily stand-up checks progress against the sprint goal set here; the sprint review inspects whether the team delivered it. Get planning wrong and the rest of the sprint is spent absorbing the error.

What planning answers: why, what, how

The Scrum Guide frames the meeting around three questions — why is this sprint valuable, what can be done, and how will it get done — and the order matters.

Settle the why first. A sprint goal you can state in one sentence is worth more than a backlog you can’t finish. The goal is the thing the team protects when the plan meets reality mid-sprint; scope flexes around it, it doesn’t flex around scope.

Then the what: the product owner brings priorities, the developers pull items they believe they can complete, and the two negotiate until there’s a commitment both sides trust. And the how: the developers break the top items into enough of a plan to start — not a Gantt chart, just enough design to know the work is real.

Inputs and outputs

Planning is only as good as what you bring to it.

• Inputs: a refined product backlog (items already clarified and sized), the team’s capacity for this sprint, and a read on recent velocity.
• Outputs: a sprint goal and a sprint backlog the team actually believes in.

Sizing happens in the room. Most teams reach a shared estimate quickly with planning poker rather than argue hours — see the estimation guide for why points beat time here.

The failure mode to watch

Overcommitment. Teams plan to 100% of theoretical capacity and forget that velocity already prices in the meetings, the interrupts, and the person who’s out on Thursday. Plan to capacity, not to hope: a plan the team finishes builds the trust that a plan the team abandons quietly destroys.

The other tell is a plan built on an unrefined backlog. If planning turns into a clarification-and-splitting session, backlog refinement isn’t happening — fix that upstream and planning gets calm.

Frequently asked questions

How long should sprint planning take?

Timebox it to about two hours per week of sprint — so up to four hours for a two-week sprint, up to a full day for a month-long one. If planning routinely runs to the wall, the backlog arrived unrefined and the team is doing refinement work it should have done earlier.

Who attends sprint planning?

The whole Scrum Team: the developers, the product owner, and the scrum master. The product owner brings the priorities and the why; the developers decide what they can realistically take on and how they’ll build it; the scrum master keeps the session timeboxed and focused. Stakeholders don’t attend.

What is the difference between the sprint goal and the sprint backlog?

The sprint goal is the single sentence that says why the sprint is worth running — the outcome the team is committing to. The sprint backlog is the set of items and tasks the team expects will get it there. The goal is fixed for the sprint; the backlog can flex around it as the team learns more.