Quick Answer (TL;DR)
Sprint planning is the meeting where an agile team decides what to build in the next sprint and how to build it. The PM presents the highest-priority items from the backlog. The engineering team estimates effort, asks clarifying questions, and commits to a sprint goal. A well-run sprint planning meeting takes 60-90 minutes for a 2-week sprint and produces a focused sprint backlog that the team can deliver with confidence.
Summary: Sprint planning turns a prioritized backlog into a concrete, time-boxed plan. The PM owns the "what" (priorities, acceptance criteria, sprint goal). The engineering team owns the "how" (task breakdown, estimates, technical approach).
Key Inputs:
- Prioritized and groomed product backlog
- Team capacity for the sprint (accounting for PTO, on-call, etc.)
- Previous sprint velocity (story points completed)
- A clear sprint goal tied to a product outcome
Time Required: 60-90 minutes for a 2-week sprint
Best For: Product managers, scrum masters, engineering leads, and anyone who participates in agile delivery.
What Is Sprint Planning?
Sprint planning is a time-boxed ceremony in Scrum where the product team aligns on what work to tackle in the upcoming sprint. A sprint is a fixed-length iteration, typically 1-2 weeks, during which the team builds, tests, and ships a potentially releasable increment of the product.
The meeting has one job: turn a prioritized backlog into a sprint backlog with a clear goal. Every person leaves the room knowing exactly what the team is building, why it matters, and who is doing what.
Sprint planning sits at the intersection of product strategy and engineering execution. The PM brings context about user needs, business priorities, and success metrics. The engineering team brings context about technical complexity, dependencies, and capacity. The meeting is where those two perspectives meet.
Without sprint planning, teams default to one of two failure modes. Either the PM assigns tasks like a project manager and engineers lose autonomy, or the team picks work ad hoc and the sprint has no coherent goal. Both patterns produce scattered output with low impact.
If you are new to agile product management, sprint planning is the ceremony you will participate in most frequently. It is also the one where the PM's preparation has the greatest impact on team velocity.
How Sprint Planning Works
The Scrum Guide divides sprint planning into two parts. In practice, most teams blend them into a single conversation, but the distinction is useful for understanding who owns what.
Part 1: What Are We Building?
The PM presents the sprint goal: a one-sentence statement that describes the outcome the team is working toward. For example: "Reduce checkout abandonment by shipping the guest checkout flow." The sprint goal is not a list of tickets. It is the reason the sprint matters.
With the goal as a frame, the PM walks through the highest-priority items in the backlog. Each item should already have acceptance criteria written. The team asks clarifying questions. "What happens if the user has an existing account?" "Do we need to support mobile?" "Is the analytics tracking in scope?"
This is where good backlog refinement pays off. If stories were clarified in a prior grooming session, Part 1 takes 20-30 minutes. If stories are raw, Part 1 turns into an hour-long grooming session and the meeting runs overtime.
Part 2: How Will We Build It?
The engineering team breaks each selected item into tasks, estimates effort (story points, hours, or t-shirt sizes), and determines who will work on what. The PM should step back here. Part 2 belongs to the engineers. The PM's job is to answer questions about scope and priority, not to suggest technical approaches.
The team uses their historical velocity to determine how much work fits in the sprint. If the team averages 40 story points per sprint and the top backlog items total 55 points, something has to drop. The PM decides what to defer based on prioritization criteria.
Key Inputs
Sprint planning depends on three inputs being ready before the meeting starts:
- Prioritized backlog. The top 15-20 items reflect the current product strategy and sprint goal. Items are ordered by priority, not by when they were created.
- Team capacity. Account for holidays, PTO, on-call rotations, and any ongoing maintenance commitments. A team of 6 engineers with one on vacation has 5 engineers of capacity.
- Previous velocity. The average number of story points (or tasks) completed in the last 3-4 sprints. This is the team's empirical throughput, not a target to optimize.
The PM's Role in Sprint Planning
The PM's value in sprint planning comes from preparation, not from talking the most. Your job is to show up with a clear priority order, well-written stories, and a sprint goal that connects the team's work to a user or business outcome.
Own the "What"
The PM is responsible for:
- Setting the sprint goal. A goal like "ship guest checkout" is useful. A goal like "work on checkout stuff" is not.
- Ordering the backlog. The team should never have to guess which item matters more. That is the PM's call.
- Writing acceptance criteria. Each story needs clear pass/fail conditions. "User can complete checkout without creating an account" is testable. "Improve checkout experience" is not.
- Answering scope questions. When engineers ask "is X in scope?", the PM answers immediately or defers it to the next sprint. Ambiguity mid-sprint causes rework.
Let Engineering Own the "How"
The team decides how to break down stories into tasks, what technical approach to use, and how long the work will take. When a PM says "this should only take a day" or "just use a simple API call," they are overstepping. Even if the PM has engineering experience, the people doing the work are better positioned to estimate it.
This boundary is the most common source of tension in sprint planning. PMs who respect it earn trust. PMs who violate it create adversarial relationships that slow the team down over time. For more on building that trust, see our guide on building trust with engineering.
Common PM Missteps
- Overloading the sprint. Optimism bias is real. PMs push more work in because "it would be great to also ship X." The result is a team that misses its commitment every sprint and stops trusting the process.
- Changing priorities mid-sprint. Unless there is a genuine production emergency, the sprint backlog should not change after planning. If the PM routinely pulls items in or swaps priorities mid-sprint, the team learns that planning is theater and stops engaging.
- Skipping refinement. When the PM brings raw, unrefined stories to sprint planning, the entire meeting becomes a grooming session. Engineers get frustrated because they are debating scope instead of committing to work.
How to Run Sprint Planning: Step by Step
Before Planning
- Groom the backlog. Run a refinement session mid-sprint (or async) so the top 15-20 items have clear titles, descriptions, and acceptance criteria. The team should have already seen these stories before planning starts.
- Write acceptance criteria. For each story, define what "done" looks like in testable terms. Use the format: "Given [context], when [action], then [result]."
- Clarify dependencies. If a story depends on another team's work, a design deliverable, or a third-party API, flag it. Dependencies that surface during planning derail the conversation.
- Calculate capacity. Know who is available. A 2-week sprint with 5 engineers, one on PTO, and one on partial on-call duty gives you roughly 3.5-4 engineers of real capacity.
For a deeper tactical walkthrough, see How to Run Effective Sprint Planning and our step-by-step sprint planning guide at How to Run Sprint Planning.
During Planning
- State the sprint goal (PM, 5 minutes). One sentence. What outcome does this sprint drive?
- Walk through top backlog items (PM + team, 30-40 minutes). Present each item. Answer questions. The team estimates effort. If a story is too large (>8 points or >3 days), break it down.
- Team commits (team, 10-15 minutes). The team selects the items they can realistically complete given their capacity and velocity. The PM does not pressure the team to take on more.
- Assign owners (team, 5-10 minutes). Each item gets an owner. Pairing decisions are made. Technical approach is briefly discussed.
After Planning
- Publish the sprint board. Move committed items to the "Sprint" column in Jira, Linear, or whatever tool your team uses. Make the sprint goal visible at the top of the board.
- Run daily standups. 15-minute check-ins to surface blockers. The PM attends to stay informed, not to manage tasks.
- Protect the sprint. If a stakeholder asks to add work mid-sprint, the PM evaluates the tradeoff and either defers it to the next sprint or swaps it for an equal-sized item. The sprint scope should not grow without a corresponding reduction.
Sprint Planning vs. Other Ceremonies
Teams new to Scrum often confuse sprint planning with other agile ceremonies. Here is how they differ:
| Ceremony | Purpose | Frequency | Who Leads | Duration (2-week sprint) |
|---|---|---|---|---|
| Sprint Planning | Decide what to build this sprint | Start of each sprint | PM + Scrum Master | 60-90 min |
| Backlog Refinement | Clarify, estimate, break down upcoming stories | Mid-sprint (1-2x) | PM | 30-60 min |
| Daily Standup | Surface blockers, sync on progress | Daily | Scrum Master | 15 min |
| Sprint Review | Demo completed work to stakeholders | End of sprint | PM + team | 30-60 min |
| Sprint Retrospective | Reflect on team process, identify improvements | End of sprint | Scrum Master | 30-60 min |
The most important relationship is between refinement and planning. Refinement is where the detail work happens. Planning is where the commitment happens. Teams that skip refinement overload planning. Teams that skip planning lose focus during the sprint.
If your team uses Kanban instead of Scrum, you do not have sprint planning in the same form. Kanban uses continuous flow with WIP limits instead of time-boxed iterations. Some teams blend the two approaches. See our comparison of Kanban vs. Scrumban for how hybrid models work.
Common Sprint Planning Mistakes
1. No sprint goal. The team commits to a list of unrelated tickets instead of a coherent outcome. Without a goal, there is no way to make tradeoff decisions mid-sprint. When something unexpected comes up, the team has no framework for deciding what to cut.
2. Overcommitting. The team takes on 50 story points when their average velocity is 38. This happens because the PM pushes for more or because the team is optimistic about a "clean" sprint. Track velocity over 3-4 sprints and use the average, not the best sprint, as your baseline.
3. Skipping refinement. When stories arrive at planning without acceptance criteria, estimates, or scope clarity, the meeting devolves into a grooming session. Engineers ask questions the PM cannot answer on the spot. The meeting runs 2+ hours and the team commits to poorly understood work.
4. The PM dictates implementation. "Just add a column to the database" or "this is a simple frontend change" from the PM kills engineering autonomy. Even if the PM has a technical background, the engineers doing the work need to own the approach. If they estimate higher than you expect, ask questions. Do not override.
5. Treating sprint planning as a status meeting. Sprint planning is forward-looking. It is about what comes next, not what happened last sprint. If the first 30 minutes are spent debriefing the previous sprint, that is a sign the team is not using sprint reviews and retrospectives effectively.
6. Not accounting for unplanned work. Every sprint has interruptions: production bugs, support escalations, last-minute requests. Teams that plan to 100% capacity have no room for these. A safer default is to plan to 70-80% of theoretical capacity and leave a buffer for the unexpected.
Prioritizing what gets into the sprint is half the battle. If your team struggles with prioritization, the RICE framework provides a structured scoring model, and IdeaPlan's RICE calculator automates the math.
Key Takeaways
- Sprint planning is a time-boxed meeting where the team commits to a focused set of work for the sprint. It is not a grooming session or a status update.
- The PM owns the "what" (priorities, sprint goal, acceptance criteria). The engineering team owns the "how" (task breakdown, estimates, technical approach).
- Good sprint planning depends on good backlog refinement. If stories are well-groomed before planning, the meeting takes 60-90 minutes. If not, it becomes a 3-hour debate.
- Track velocity over 3-4 sprints and plan to 70-80% of capacity. Overcommitting erodes trust and makes the process feel broken.
- Protect the sprint. Changes mid-sprint should be rare and should always involve a tradeoff (add one item, remove another of equal size).
- If Scrum sprints feel too rigid, explore Kanban or Scrumban as alternative delivery models. The right ceremony structure depends on your team's context, not on dogma.