Sprint Planning Meeting in Scrum

Sprint Planning starts the sprint.

During Sprint Planning, the Scrum Team decides why the sprint is valuable, what can be done during the sprint, and how Developers will begin doing the work.

The result should not be a perfect plan. Product development is too uncertain for that. The result should be a Sprint Goal, a selected set of Product Backlog items, and enough of a plan for Developers to begin responsibly.

Who This Page Is For

This page is for Scrum Teams that want Sprint Planning to create focus, confidence, and a realistic starting plan.

It is especially useful for:

Product Owners preparing Product Backlog items for Sprint Planning
Developers deciding how much work they can responsibly select
Scrum Masters helping planning become more focused and collaborative
Teams that overcommit or carry too much unfinished work from sprint to sprint
Leaders who want to understand why Sprint Planning is not simply assigning work

What This Page Covers

This page explains the purpose of Sprint Planning, who attends, what happens during the meeting, how the Sprint Goal is created, how Developers select work, and why capacity-driven planning is often more useful than simply filling a sprint from average velocity.

It also covers common Sprint Planning problems, including overcommitment, weak Product Backlog refinement, vague Sprint Goals, and planning every task in too much detail.

What Is Sprint Planning?

Sprint Planning is the Scrum event that starts the sprint.

The whole Scrum Team participates: the Product Owner, Scrum Master, and Developers. The Product Owner brings the most important Product Backlog items and explains the goals behind them. Developers ask questions, discuss the work, consider their capacity, and decide what they believe they can complete.

A good Sprint Planning meeting answers three questions:

Why is this sprint valuable?
What can be done this sprint?
How will the selected work get done?

Those questions do not need to be answered in three separate phases. In real Sprint Planning conversations, the what and how usually blend together. Developers often need to discuss how they might do an item before they can decide whether it belongs in the sprint.

The Goal of Sprint Planning

The goal of Sprint Planning is to choose valuable work and create enough shared understanding to begin.

Sprint Planning should not become a long design session, a full task-discovery exercise, or a negotiation where the Product Owner pressures Developers into taking more work than they believe they can finish.

The Product Owner should leave Sprint Planning confident that Developers understand the purpose of the sprint. Developers should leave confident that they have selected a reasonable amount of work and know how to start.

That does not mean nothing will change. The plan will change as Developers learn during the sprint. Scrum expects that.

Who Attends Sprint Planning?

The whole Scrum Team attends Sprint Planning.

The Product Owner explains the most important Product Backlog items and the product goals behind them. Developers discuss the items, ask questions, estimate or break down work as needed, and decide what they can complete. The Scrum Master helps the event stay focused and useful.

Stakeholders may attend if invited and if their presence helps the Scrum Team understand the work. They should not turn Sprint Planning into a requirements debate or approval session.

Create or Refine the Sprint Goal

A Sprint Goal gives the sprint a purpose.

Without a Sprint Goal, Sprint Planning can become an exercise in filling the sprint with unrelated Product Backlog items. Developers may complete many items and still have no clear sense of what the sprint was meant to achieve.

The Product Owner may arrive with an initial goal in mind. During Sprint Planning, the Scrum Team may revise that goal based on the work selected and what Developers believe is possible.

A useful Sprint Goal helps the Scrum Team make tradeoffs during the sprint. When work is harder than expected, Developers and the Product Owner can ask, “What adjustment best protects the Sprint Goal?”

Selecting Product Backlog Items

The Product Owner brings the most important Product Backlog items to discuss.

Developers do not merely accept the list. They ask questions, consider dependencies, identify risks, discuss the Definition of Done, and decide how much work they believe they can complete.

This decision belongs to Developers because Developers are doing the work. The Product Owner may explain why an item matters or ask whether a smaller version would work. The Scrum Master may help the Scrum Team avoid overcommitment. But Developers make the forecast.

A Product Backlog item does not need to be perfectly understood before Sprint Planning. But if Developers cannot make a responsible forecast, the item probably needs more refinement before it belongs in the sprint.

Capacity-Driven Sprint Planning

Capacity-driven planning starts with the real capacity Developers have for the sprint.

Developers consider holidays, vacations, support responsibilities, meetings, product-release work, and other known demands on their time. Then they discuss Product Backlog items and decide what fits.

This is often more useful than simply saying, “Our average velocity is 40 points, so let’s take 40 points.” Velocity can inform the conversation, but capacity matters in the actual sprint the Scrum Team is planning.

For example, if two Developers are out for several days, or if the Scrum Team has a major support obligation during the sprint, average velocity may be misleading.

Capacity-driven planning helps Developers make a more responsible forecast.

Planning the Work Without Planning Everything

Developers need enough of a plan to begin.

They may identify tasks, discuss technical approaches, sketch designs, pair on uncertain work, or decide which items to start first. Some teams break down every selected Product Backlog item into tasks. Others do this only for the first few items. Some teams use a lighter approach.

The plan should be useful, not performative.

No one should expect Developers to discover every task during Sprint Planning. Complex work reveals new tasks as the sprint unfolds. The Sprint Backlog should change as Developers learn.

A Scrum Team that tries to plan every detail usually spends too long in Sprint Planning and still misses things.

How Long Should Sprint Planning Take?

The Scrum Guide sets a maximum timebox of eight hours for a one-month sprint. Shorter sprints usually need less time.

Experienced Scrum Teams often need far less than the maximum. A two-week sprint might need 90 minutes to two hours. New Scrum Teams may need more time while they learn how much discussion is enough.

If Sprint Planning regularly feels too long, the problem is often not the meeting itself. The real issue may be weak refinement, oversized Product Backlog items, unclear acceptance criteria, or too much task-level planning.

Common Sprint Planning Problems

If the Scrum Team first understands the work during Sprint Planning, planning will feel slow and frustrating.

Upcoming Product Backlog items should usually be discussed before Sprint Planning. Refinement should create enough shared understanding for a responsible planning conversation. For more detail, see Your Team Won’t Think of Everything in Sprint Planning Meetings. and That’s OK..

Developers Overcommit

Developers may take too much work because they want to please the Product Owner, satisfy stakeholders, or show progress.

Overcommitment creates predictable carryover, rushed work, and pressure to weaken the Definition of Done.

The Sprint Goal Is Too Vague

A Sprint Goal such as “finish these eight items” does not provide much guidance.

A good Sprint Goal gives Developers and the Product Owner a way to make tradeoffs when the sprint does not go exactly as expected. For more detail, see The Goal of Sprint Planning.

The Product Owner Dictates the Sprint

The Product Owner orders the Product Backlog and explains what matters.

Developers decide what they can complete. Sprint Planning should be collaborative, not a handoff of assignments.

The Plan Is Treated as a Contract

The Sprint Backlog is a plan, not a contract.

Developers should adapt it as they learn. New tasks may appear. Some tasks may disappear. The important thing is protecting the Sprint Goal and creating a done increment.

The Scrum Team Tries to Identify Every Task

Trying to identify every task creates false confidence.

The Scrum Team needs enough of a plan to start, not a detailed prediction of everything that will happen.

Before You End Sprint Planning

Before ending Sprint Planning, the Scrum Team should be able to answer these questions:

Why is this sprint valuable?
What is the Sprint Goal?
Which Product Backlog items have Developers selected?
Do Developers believe the selected work can be completed within the sprint?
Is there enough shared understanding to begin?
What are the biggest risks or uncertainties?
How will Developers start the work?
What should the Product Owner be ready to clarify during the sprint?

This is not a checklist to make Sprint Planning bureaucratic. It is a way to confirm the Scrum Team is leaving with enough focus and confidence.

FAQ

What is sprint planning?

Sprint Planning is the Scrum event that starts the sprint.

The Scrum Team uses it to decide why the sprint is valuable, what can be done during the sprint, and how Developers will begin doing the work.

Who attends sprint planning?

The whole Scrum Team attends: the Product Owner, Scrum Master, and Developers.

Stakeholders may attend by invitation when their presence helps, but Sprint Planning belongs to the Scrum Team.

Who decides what goes into the sprint?

Developers decide how much work they believe they can complete.

The Product Owner explains priorities and desired outcomes. The final forecast of what can be done belongs to Developers.

How long should sprint planning take?

The maximum timebox is eight hours for a one-month sprint, with shorter sprints usually requiring less time.

Many experienced Scrum Teams can complete Sprint Planning in less than the maximum. If planning regularly takes too long, improve refinement and reduce unnecessary task-level detail.