How Do You Run a Sprint Planning Meeting?

How do you run a sprint planning meeting?

Planning runs long for one reason: the team is discovering and deciding at the same time.

Separate those two activities and the meeting shortens dramatically.

This guide covers what planning produces, what must happen beforehand, how to run the meeting, and how to close it properly.

Quick answer: Sprint planning produces two things: a sprint goal describing what the sprint should achieve, and a sprint backlog of items the team believes it can complete. Run it by refining the backlog beforehand, calculating real capacity, agreeing the goal first, then pulling items until capacity is reached. For a two-week sprint it should take under two hours, and well-prepared teams routinely finish in one.

What Sprint Planning Produces

The meeting produces a sprint goal and a sprint backlog, agreed by the people who will deliver them.

A sprint goal and a sprint backlog

The sprint goal is one sentence describing what the sprint should achieve — "customers can reset their own passwords without contacting support".

The sprint backlog is the set of items selected to achieve it. The goal matters more than the list, because it tells the team what to protect when something goes wrong mid-sprint.

Who attends and what each person does

The product owner brings the ordered backlog and explains what is wanted and why. The development team decides how much it can take on and how the work will be approached. The scrum master facilitates and keeps the meeting to time.

The critical division: the product owner does not decide how much the team commits to, and the team does not decide the priority order.

How long it should take

Scrum guidance sets a ceiling of eight hours for a one-month sprint, scaling proportionally — around two hours for two weeks.

That is a limit, not a target. A team that refines properly beforehand should finish in half of it.

The Sprint Planning Agenda

Item Purpose Time (2-week sprint) Review last sprint's carryover Decide what returns 5 min Confirm capacity Establish the limit 5 min Propose the sprint goal Give the sprint a purpose 10 min Walk the top of the backlog Clarify the selected items 30 min Pull items to capacity Build the sprint backlog 20 min Break down early items Make work startable 15 min

Confirm the commitment out loud

Before the Meeting

Three things must happen before planning: the backlog is refined, capacity is calculated, and carryover is reviewed.

Refine the backlog in a separate session

If planning is where the team first reads and discusses the stories, it will run long every time.

Hold refinement mid-sprint — typically an hour — where upcoming items get clarified, sized and given acceptance criteria. Planning then becomes selection from ready items, which is fast.

A useful bar is a definition of ready: acceptance criteria written, no unresolved blockers, sized, and any designs available. Items failing it do not enter planning.

Calculate real capacity

Count each person's available days, subtract leave and known commitments, then apply your focus factor — the share of time that historically goes to sprint work, commonly 60 to 75 percent.

A two-week sprint with five developers looks like fifty person-days. After holidays, support rotation and the usual meeting load, the real figure is often closer to thirty. Teams that skip this step overcommit every sprint and misread it as a delivery problem.

Check what is carrying over

Look at unfinished items before planning starts. Do they return, and at what size?

An item that has carried over twice is telling you something — it is blocked, too large, or not actually a priority. Investigate rather than rolling it again automatically.

Running the Meeting

Agree the goal before selecting items, pull work until capacity is reached and then stop, and break down enough of the early items that work can start immediately.

Agree the sprint goal first

The product owner proposes what the sprint should achieve; the team discusses whether it is realistic.

Setting the goal first shapes selection. Without it, the team picks the top items by priority order and ends up with a collection of unrelated work that cannot be traded off against anything when the sprint is disrupted.

Pull items until capacity is reached

Work down the ordered backlog, clarifying each item, and add it to the sprint until the capacity figure is reached.

Then stop. The pressure to add one more item is constant and should be resisted — capacity is a limit rather than a target, and estimates are uncertain in both directions.

Reserve roughly 10 to 15 percent for the unplanned work that arrives every sprint. This is predictable in aggregate even though the specifics are not.

Break down the first few items

Decompose the items the team will start immediately into tasks with owners.

There is no need to break down everything — items later in the sprint can be decomposed when reached. Doing it for the first few means work can begin the moment planning ends rather than the following morning.

Ending Planning Properly

Close by confirming the commitment aloud, checking that no single person is a bottleneck, and recording what was deliberately left out.

Confirm the commitment out loud Ask directly: does the team believe it can deliver this sprint backlog and achieve the goal?

A silent nod is not a commitment. Saying it explicitly surfaces the doubt that someone was holding privately, and that doubt is almost always accurate.

Check nobody is a single point of failure

Look at whether the sprint depends entirely on one person. If half the items require the same specialist, the sprint fails if they are ill.

Rebalancing at planning is easy; discovering it in week two is not.

Record what you deliberately excluded

Note the items considered and not selected, briefly.

This is useful when a stakeholder asks why something is not being worked on — the answer is that it was considered and ranked below the selected work, which is a better answer than "it did not come up". Keeping the sprint and backlog in one place, as most tools do, makes this visible without extra effort.

Common Sprint Planning Mistakes

The three habits that make planning painful are discovering stories in the meeting, planning at theoretical capacity, and committing to a task list with no goal.

Discovering the stories during planning

If the first time anyone reads a story is in planning, the meeting becomes a requirements workshop with the whole team present.

Refine separately. This single change is usually the difference between a three-hour planning session and a one-hour one.

Planning to full theoretical capacity

Committing to everything that fits on paper guarantees carryover, because no allowance exists for the incident, the urgent request or the sick day that arrives every sprint.

Committing to a task list instead of a goal

Without a goal, every item has equal weight. When something slips mid-sprint, the team drops whatever is easiest rather than whatever matters least.

With a goal, the trade-off is obvious and can be made by the team without escalation — which is precisely why the goal exists.