SkilsMVP

Sprint planning guide

How to run an effective sprint planning meeting

Sprint planning is one of the five Scrum ceremonies — and the one that sets the direction for the entire sprint. Done well, it gives every team member clarity on what they are building and why.

What is sprint planning?

Sprint planning is a time-boxed meeting — usually 2 hours for a 2-week sprint — where the team decides what to build in the next sprint. The Product Owner brings prioritized backlog items and explains the business value behind them. The development team then selects what they can realistically deliver and breaks the work into tasks. The meeting ends with a committed sprint backlog and a clear sprint goal that unifies the work.

Who is in the room

Sprint planning requires three roles. Each has a distinct job — and mixing up those jobs is one of the most common ways the meeting goes sideways.

Product Owner (or PM)

Sets the agenda

Brings the prioritized backlog. Explains the WHY behind each item. The PO decides what to build — not the team.

Scrum Master

Facilitates

Keeps the meeting on track. Timesboxes each section. Records the sprint goal and the committed backlog at the end.

Development Team

Commits

Selects items, breaks them into tasks, and provides estimates. The team decides how much work to take on — not the PO.

The 3-part agenda

A well-run sprint planning meeting moves through three distinct phases. Each phase has a clear owner and a clear output.

Part 1

What will we build?(Sprint Goal)

The PO presents the top backlog items. The team asks clarifying questions. Together, they define the Sprint Goal: a one-sentence statement of what the sprint will achieve.

Example sprint goal

“By the end of this sprint, users can complete the onboarding flow and see their personalized dashboard.”

Part 2

How much can we commit to?

The team selects items from the backlog until their velocity (average story points per sprint) is reached. If the team typically completes 30 points per sprint, they select items totaling ~30 points.

Part 3

How will we build it?

The dev team breaks each backlog item into technical tasks and assigns rough estimates. The PO is available for questions but does not drive this part.

Definition of Ready (for backlog items)

Before an item enters sprint planning, it must meet the Definition of Ready. Items that fail this bar get sent back for refinement — they do not enter the sprint.

  • Written as a user story: 'As a [user], I want [goal] so that [reason]'
  • Estimated (in story points)
  • Has clear acceptance criteria
  • Dependencies identified and resolved
  • Small enough to complete in one sprint

Common sprint planning mistakes

Most sprint planning failures are predictable. Here are the four that come up again and again — and why each one matters.

No sprint goal

The team commits to items but has no unifying objective. Without a goal, every item feels equally important and nothing gets ruthlessly prioritised when things go sideways.

Over-commitment

Committing to 120% of velocity and burning out the team. Velocity exists precisely so teams can make honest commitments — ignore it and you guarantee a failed sprint.

Backlog not groomed

Items arrive unclear and the meeting becomes requirements work. Sprint planning is for committing to known work, not discovering what the work actually is.

PO absent

Cannot answer questions — meeting stalls. The Product Owner's job is to show up prepared. An absent PO is the single fastest way to derail sprint planning.

What each role does in sprint planning

Sprint planning is not just for engineers. PM, BA, and Scrum Master each have specific jobs before and during the meeting.

PM / PO

  • Prepare the backlog before the meeting
  • Show up with the top 10–15 items in priority order
  • Be ready to explain the WHY for each item
  • Accept or defer items based on team capacity

Business Analyst

  • Ensure acceptance criteria are written for every item entering the sprint
  • Clarify edge cases and business rules before the meeting
  • Support the PO in answering team questions during Part 1

Scrum Master

  • Start on time and timebox each section
  • Record the sprint goal and committed items
  • Keep the conversation focused — push requirements discussions out of the room
  • Facilitate conflict when the team and PO disagree on scope

Go deeper

Learn the full Agile framework

Sprint planning is one piece of the Agile system. Understand Scrum, Kanban, retrospectives, and every ceremony in the full guide.

Read the Agile guide