Sprint planning is the ceremony that translates backlog priorities into a sprint commitment. Done well, it produces a team that understands what they are building, why it matters, and what done looks like. Done poorly, it produces a list of tickets that nobody fully committed to and a sprint goal nobody remembers.
- The sprint goal should be one sentence that the team can hold in mind all sprint
- Velocity-based capacity planning prevents the over-commitment that destroys sprint credibility
- Acceptance criteria must be defined before items enter the sprint — not during execution
- The team pulls the backlog into the sprint — the PO and SM do not push
Preparing for sprint planning
The Product Owner brings a refined backlog: top items estimated, acceptance criteria written, and dependencies identified. The team arrives knowing the sprint goal theme and having reviewed the top backlog items. Sprint planning is not the first time the team sees the backlog.
Setting the sprint goal
The sprint goal is a one-sentence statement of what the sprint will accomplish from a business value perspective. It is not a list of tickets. A good sprint goal: "Complete the checkout flow so users can purchase without contacting support." A bad sprint goal: "Work through tickets CHK-12 through CHK-19."
Capacity-based commitment
Calculate available team capacity (people × sprint days × hours per day × focus factor). Compare to the estimated effort of backlog items selected. The team commits to what their capacity supports — not to the backlog top until the sprint is full.
Defining done
Each sprint item should have acceptance criteria agreed before the sprint starts. "Done" is not "coded" — it includes tested, reviewed, documented, and deployable. Teams that skip acceptance criteria spend the last two days of every sprint arguing about whether things are done.
Frequently asked questions
The Scrum Guide recommends a maximum of 8 hours for a one-month sprint, scaled proportionally for shorter sprints. Most teams complete it in 2–4 hours with good backlog preparation.
Clarify acceptance criteria, answer questions about priority and business context, and confirm the sprint goal. The PO does not assign work — the team self-organizes around the goal.
Use historical velocity data to cap sprint capacity. A team that consistently over-commits has a planning problem, not an execution problem.
Request Sprint Planning: A Practical Guide for Scrum Teams
Answer a few quick questions. We will recommend the right engagement and follow up within one business day.
Ready to put this into practice?
PMOstart provides consulting, fractional PMO leadership, templates, and tools to help you apply what you just read.