How to Run a Scrum Sprint Planning Meeting

A well-run Sprint Planning meeting sets the team up for a productive sprint. Follow this step-by-step facilitation guide to run sessions that are focused, fast, and realistic.

Start planning poker for estimation Back to guides

Before the meeting: preparation checklist

Refine the top of the backlog — the highest-priority items should be clear, estimated, and small enough to fit in a sprint.
Confirm capacity — note planned leave, company holidays, and support rotations. Express capacity as available developer-days or story points.
Review the previous sprint — use the retrospective and review insights to inform what's realistic this sprint.
Prepare the Sprint Goal draft — the Product Owner usually arrives with a proposal; the team refines it together.

Step-by-step facilitation guide

Open with the Sprint Goal (5–10 min)
The Product Owner presents the goal. The team discusses whether it's achievable, clear, and valuable. Adjust the wording together until everyone is aligned.
Review capacity (5 min)
Sum up available working days per developer. Compare against your team's historical velocity in story points to set a realistic upper limit for the sprint.
Select backlog items (15–30 min)
Pull items from the top of the refined backlog that support the Sprint Goal and fit within capacity. Use story points as a lightweight sizing check. Quickly re-estimate any item that changed significantly since refinement.
Run planning poker for unclear estimates (10–20 min)
If the team needs to re-estimate or size new items, use planning poker. Open a free online session, add the stories, vote simultaneously, discuss differences, and converge — usually within 2–3 rounds per story.
Break stories into tasks (15–20 min)
Developers identify the work needed to meet the Definition of Done. Capturing tasks surfaces hidden complexity and dependencies early.
Identify risks and dependencies (5 min)
Call out anything that could block delivery: missing designs, third-party APIs, external approvals. Add explicit tasks or spikes for each risk.
Commit and close (5 min)
The team confirms the Sprint Backlog and the Sprint Goal. The Scrum Master updates the sprint in your project management tool and closes the meeting.

Facilitation tips

Guard the timebox — if a discussion drifts, park the item and continue. Resolve it in a follow-up or during the sprint.
Keep the Sprint Goal front and centre — every item selected should serve it.
Don't commit to 100% capacity — leave 10–20 % for unexpected work, bugs, and support.
<strong>Use remote-friendly tools</strong> — if your team is distributed, share screens, use a virtual board, and run online planning poker to vote simultaneously.
Record key decisions — note the Sprint Goal, capacity, and any deferred items in your backlog tool before everyone leaves.

Common anti-patterns to avoid

Starting with an unrefined backlog — leads to long discussions, missed context, and poor estimates.
Skipping the Sprint Goal — leaves the team without a compass when priorities shift mid-sprint.
Over-committing — optimistic planning that ignores capacity leads to failed sprints and low morale.
Estimation rabbit holes — timeboxing each story estimate to 5–10 minutes keeps the session moving.
The Product Owner deciding what the team can do — Developers own the plan; the Product Owner owns the goal.

The Scrum Master's role in sprint planning

The Scrum Master does not run sprint planning in the traditional sense of a meeting chair. Their role is to facilitate the process — ensuring the meeting starts on time, stays within its timebox, and produces the three required outputs (Sprint Goal, Sprint Backlog, and initial task breakdown). They intervene when the discussion goes off-track, not when it goes deep.

Practically, the Scrum Master prepares by confirming that backlog items are refined and ready, that capacity is calculated, and that the team has the context they need. During the meeting, they track time, surface blockers, and call for re-votes when planning poker discussions stall.

Before planning: confirm with the Product Owner that the top backlog items are ready, estimated, and ordered by priority.
During planning: timebox each discussion, manage planning poker rounds, and ensure the Sprint Goal is agreed before item selection begins.
After planning: record the Sprint Goal in the team's tracking tool, share the sprint backlog with stakeholders, and schedule a mid-sprint check-in if the sprint has unusually complex stories.

The Product Owner's role in sprint planning

The Product Owner is the voice of business value in sprint planning. Their primary job is to propose the Sprint Goal, clarify the priority and scope of backlog items, and answer questions about acceptance criteria. They do not assign tasks or dictate how the team will work — that autonomy belongs to the developers.

The most effective Product Owners arrive at sprint planning having already had a pre-planning conversation with the Scrum Master. They know which stories are candidates for the sprint, they can articulate why each story matters to the business, and they have pre-answered common scope questions so the team can move quickly.

Propose the Sprint Goal: frame it as a business outcome, not a list of features.
Clarify scope, not implementation: explain what success looks like for each story without prescribing how the team builds it.
Be available for the full planning session: Product Owners who leave after presenting the goal leave the team unable to answer scope questions that arise during task breakdown.

Running sprint planning effectively for remote teams

Remote sprint planning introduces challenges that co-located planning handles organically: side conversations, whiteboard sketching, and the visual cues that signal confusion or disagreement. A well-facilitated remote planning session compensates for these through structure and tooling.

Keeping remote participants engaged

Cameras on during voting: planning poker discussion quality improves significantly when participants can see each other. Make camera usage a team norm for planning sessions, not an optional nicety.
Round-robin contributions for task breakdown: in the task breakdown phase, go around the virtual room and ask each participant to name one task for the current story. This prevents one person from dominating while others passively observe.
Use the parking lot visibly: maintain a shared, visible list of topics that came up but are out of scope for planning. Team members contribute more freely when they know their ideas are captured, not dismissed.

Tools that support remote sprint planning

Online planning poker tool: for simultaneous, unanchored estimation. ScrumVote works directly in the browser — share a link, no installation required.
Virtual whiteboard: for task breakdown and dependency mapping when stories are complex. Useful for visual thinkers who find text-only planning restrictive.
Video conferencing with persistent chat: keep the chat channel open throughout the session. Questions that arise mid-discussion can be parked in chat without interrupting the flow.

Sprint planning readiness checklist

Use this checklist before every sprint planning session. If more than two items are not checked, postpone planning until they are resolved — a planning session built on incomplete inputs wastes more time than delaying by one day.

The Product Backlog is ordered with clear priorities for the top 1.5× sprint's capacity worth of stories.
All candidate stories have accepted acceptance criteria and are signed off by the Product Owner.
All candidate stories have story point estimates from a recent planning poker session.
Team member availability for the sprint is confirmed (holidays, on-call rotation, cross-team commitments).
Sprint capacity is calculated and agreed with the Scrum Master.
The Product Owner has a draft Sprint Goal ready to propose — not necessarily final, but a starting point for discussion.

Sprint planning meeting FAQ

Should the sprint planning meeting have a fixed agenda?

Yes — and publishing it in advance improves preparation quality. A typical agenda: (1) Sprint Goal proposal and discussion (15–20 min), (2) Backlog item selection (30–45 min), (3) Estimation of any unestimated items using planning poker (20–30 min), (4) Task breakdown for first 2–3 days (20–30 min), (5) Commitment and close (5–10 min).

What do we do if the sprint planning runs over time?

Stop at the timebox, even if the plan is incomplete. An overrun planning session is a symptom, not a solution. The root cause is almost always insufficient refinement. Note what was not decided, assign refinement tasks, and start the sprint with the plan as it is. Use the retrospective to address the preparation gap.

Can we add stories to the sprint after planning ends?

The Sprint Backlog is owned by the development team and can be updated during the sprint. However, adding stories should be an exceptional event, not a routine one. Every addition displaces planned work — the team must explicitly agree to what gets removed or reduced when something is added.

How do we handle a team member who is new and doesn't know how to estimate?

Include them as a full voter from day one. New team members often raise questions that experienced team members have stopped asking, which improves estimate quality. Use your reference stories explicitly so they have calibration anchors. Accept that their first few sprints of estimates will be learning data.

Run your next sprint planning with free online planning poker

Run Sprint Planning with free online planning poker