Sprint Planning: How to Run It + Agenda [2026]
A. Togay Koralturk, Best-Selling PMP Author
Last updated on August 23, 2026
12 min read
Every sprint lives or dies by the hour or two that kicks it off. Get sprint planning right and the team leaves with a clear goal, a realistic amount of work, and a shared plan; get it wrong and you get an overcommitted backlog, a vague target, and a sprint that unravels by day three. It is the least glamorous of the Scrum events and quietly the most important. This guide explains sprint planning in full — what it is, who attends, how long it should take, the sprint goal and backlog it produces, a step-by-step agenda for running it, and how it appears on the PMP and CAPM exams.
What is sprint planning?
Sprint planning is the Scrum event that begins each sprint, where the whole Scrum team collaborates to decide what work to take on and how they will deliver it. It is the first of the Scrum events, and its job is to turn a prioritized backlog into a concrete, achievable plan for the next one to four weeks — anchored by a shared sprint goal.
The event answers a deceptively simple question: what will this team deliver by the end of the sprint, and how? The product owner brings the priorities and the "why," the developers decide how much they can realistically commit to and work out the "how," and the Scrum Master keeps the session focused and within its timebox. Two things exist at the end that did not exist at the start: a sprint goal that gives the sprint a single, coherent purpose, and a sprint backlog — the set of items the team has selected plus its plan for building them. Everything the team does for the rest of the sprint traces back to what happens in this meeting.
Why sprint planning matters
Sprint planning matters because it converts a long, shifting product backlog into a focused, bounded commitment the team actually believes in. Without it, a team either drifts through the sprint without a clear target or has work pushed onto it from above. With it, the team walks out aligned on one goal and confident the work fits the time available.
Its real value is threefold. First, it creates alignment: everyone leaves understanding the same goal and the same priorities, so day-to-day decisions during the sprint don't need constant re-litigation. Second, it produces a realistic forecast: because the developers — the people doing the work — decide how much to take on, the commitment reflects genuine capacity rather than wishful thinking. Third, it gives the sprint a purpose beyond a checklist of tickets: the sprint goal is something the team can rally around and, if trade-offs arise mid-sprint, use to decide what matters most. A sprint without a goal is just a batch of tasks; a sprint with one is a coordinated push toward something worth delivering.
Ready to take the next step in project management?
200,000+ Learners Trust Our Instructors
Who attends sprint planning?
Sprint planning is a whole-team event: the entire Scrum team participates, because a plan built without everyone who owns a piece of it is a plan that fails. Each role carries a distinct responsibility, and getting those responsibilities straight is half the battle.
| Role | Responsibility in sprint planning |
|---|---|
| Product owner | Brings the prioritized product backlog, proposes how the product could increase in value, and clarifies items so the team understands the "what" and "why." |
| Developers | Select how many items to take on based on capacity, break the work into a plan, and own the forecast — they decide how much work is realistic. |
| Scrum Master | Facilitates the event, keeps it inside the timebox, and coaches the team to plan effectively; does not dictate scope or commitment. |
| Stakeholders (optional) | May be invited for specific technical or domain advice, but do not decide the sprint's scope. |
The critical point — and a favorite of exam writers — is that the developers, not the product owner or a project manager, decide how much work enters the sprint. The product owner influences priority and value; the team owns capacity. The Scrum Master facilitates but never commits the team to work on its behalf.
How long is sprint planning? The timebox
Sprint planning is timeboxed to a maximum of eight hours for a one-month sprint, and proportionally less for shorter sprints. The timebox is a ceiling, not a target — if the team plans well and the backlog is refined, it often finishes comfortably under it. Most teams run two-week sprints and spend two to four hours planning.
| Sprint length | Sprint planning timebox (maximum) |
|---|---|
| One week | ~2 hours |
| Two weeks | ~4 hours |
| Three weeks | ~6 hours |
| One month | 8 hours |
If planning routinely runs to the very end of the timebox, it is usually a symptom rather than a rule: the product backlog was not refined beforehand, so the team is discovering and estimating work during planning that should have been sorted out earlier. Well-prepared teams treat the timebox as generous headroom, not a deadline they scramble to meet.
The three topics: why, what, and how
The Scrum Guide frames sprint planning around three topics the team works through in order — why, what, and how. Together they move the team from purpose to a concrete plan.
- Why is this sprint valuable? (The sprint goal.) The product owner proposes how the product could increase in value this sprint, and the whole team collaborates to define a single sprint goal, a concise statement of what the sprint is trying to achieve. This comes first on purpose: the goal shapes which work is worth selecting.
- What can be done this sprint? (Selecting the backlog items.) The developers, discussing trade-offs with the product owner, select items from the top of the product backlog that serve the goal and fit their capacity. This is where the team's past performance — its velocity — and its actual availability this sprint guide how much to pull in.
- How will the chosen work get done? (The plan.) For each selected item, the developers decompose the work into a plan (often tasks) detailed enough to give them confidence they can deliver it. Items are broken down until the team can comfortably start work on day one.
The output of working through all three is the sprint backlog: the sprint goal, the selected product backlog items, and the plan to deliver them. Notice the sequence — value first, scope second, plan third — which stops teams from committing to a pile of tasks with no unifying purpose.
Inputs and outputs
Good planning depends on good inputs. The team should arrive with several things already in hand, and leave with two clear artifacts. Treating planning as the place to use preparation — rather than to do it — is what keeps the event short and focused.
| What it includes | |
|---|---|
| Inputs (bring these in) | A refined product backlog, the definition of done, the team's capacity for this sprint (accounting for leave, holidays, and support duties), past velocity, and the latest product increment. |
| Outputs (leave with these) | The sprint goal and the sprint backlog — the selected items plus the plan and the goal that ties them together. |
The two inputs teams most often neglect are capacity and the definition of done. Capacity is what turns velocity from a vanity number into a realistic forecast: an average velocity of 40 points means little in a sprint where half the team is on leave. The definition of done is the shared standard for what "finished" means, and without it the team plans against a moving target. Sizing the selected items with story points and forecasting with velocity turn the "what can be done" discussion from guesswork into a grounded estimate.
How to run a sprint planning meeting
A well-run sprint planning meeting follows a predictable flow. The exact agenda varies, but the sequence below works for most teams and maps cleanly onto the three topics above:
- Confirm capacity and readiness. Start by establishing how much time the team genuinely has this sprint — factoring in leave, holidays, meetings, and any support rotation — and confirm the top of the backlog is refined enough to plan.
- Review recent progress. Briefly look at the last sprint's outcome and the current product increment so the team plans from where it actually is.
- Propose and agree the sprint goal. The product owner proposes the value the sprint should deliver; the team shapes it into a single, clear sprint goal.
- Select backlog items. Working from the top of the prioritized backlog, the developers pull in items that serve the goal and fit their capacity, clarifying details with the product owner as they go.
- Break the work into a plan. For each selected item, the team decomposes the work into tasks or a plan detailed enough to start, surfacing dependencies and risks early.
- Sanity-check the commitment. Step back and confirm the selected work realistically fits capacity and genuinely delivers the sprint goal. Trim or adjust if it doesn't.
- Confirm the sprint backlog. Agree the final sprint goal, selected items, and plan. The team leaves ready to start, and progress is then tracked day to day with a burndown chart.
The whole flow should feel like a funnel: from "how much time do we have" down to "here is exactly what we'll build and how." When it works, everyone leaves with the same picture in their head.
Best practices and common pitfalls
The difference between planning that helps and planning that wastes an afternoon usually comes down to a handful of habits:
- Refine the backlog beforehand. The single biggest time-saver: come in with the top items already discussed and estimated, so planning is about selecting work, not discovering it.
- Plan to capacity, not to velocity. Velocity is a starting forecast; adjust it down for leave, holidays, and support duties. Committing to an average velocity in a below-average-capacity sprint is planning to fail.
- Anchor on a single sprint goal. Resist the pull to plan a disconnected list of tickets. A clear goal keeps the sprint coherent and guides mid-sprint trade-offs.
- Let the team own the commitment. The developers decide how much to take on. When a stakeholder or manager dictates scope, the forecast stops being real and accountability evaporates.
- Don't overcommit. Consistently pulling in more than the team can finish erodes trust in the forecast and demoralizes the team. It is better to finish a focused sprint than to carry half-done work forward.
The most common failure is a subtle one: treating sprint planning as a scope-cramming session rather than a forecasting exercise. When the goal becomes "fit in as much as possible," the sprint loses its purpose and the team loses its rhythm.
Sprint Planning on the PMP® and CAPM® Exams
Because the current PMP exam devotes a large share of its content to agile and hybrid ways of working, iteration planning — the generic term for sprint planning — shows up regularly. The facts worth locking in: sprint planning starts the sprint, is timeboxed, produces a sprint goal and a sprint backlog, and belongs to the whole team, with the developers owning how much work to commit to. The exam frames the project manager as a servant leader who facilitates the event rather than dictating the plan.
Situational questions tend to test judgment rather than definitions: a team is pressured to commit beyond its capacity, a manager tries to set the sprint scope, or a sprint has no clear goal. The right answer almost always protects the team's ownership of the forecast, adjusts commitment to real capacity, and insists on a coherent goal. The CAPM tests the same material a little more directly — often the timebox, the roles, or the outputs of sprint planning. Our PMP Complete Study Guide, the most complete on the market, covers iteration planning and the full set of agile events and how they're tested.
PMP Practice Question: Sprint Planning
A development team's average velocity is a steady 40 story points per two-week sprint. For the upcoming sprint, two of its five developers will be on leave for several days, and the team is also covering a production-support rotation. During sprint planning, the product owner asks the team to commit to 40 points again "to keep our velocity consistent and the release forecast stable."
What should the team do?
a) Commit to 40 points again, since a consistent velocity keeps the product owner's release forecast stable and predictable.
b) Forecast against this sprint's reduced capacity, selecting only the work the team can realistically complete and shaping a sprint goal around it.
c) Commit to 40 points but agree upfront that any unfinished items will simply roll into the next sprint.
d) Keep the 40-point target but have the product owner swap in the highest-value items so the most important work is still delivered.
Correct answer: B.
Rationale: Velocity is a capacity-based forecast, not a fixed quota, and the developers own the decision of how much work to pull. With two of five developers away and a support rotation running, the honest forecast is smaller, and the team should select only what it can genuinely complete and shape a sprint goal around that. Choice a) keeps the chart stable by building the plan on people who are not there, and the missed commitment it guarantees is what actually destabilizes the release forecast; choice c) is planned failure, committing to work the team already expects to roll over, which leaves the sprint without an achievable goal and quietly teaches everyone that the commitment means nothing; choice d) is the subtle trap, because swapping in higher-value items changes which work goes unfinished rather than whether the team is overcommitted, and it moves the "how much" decision to the product owner when that call belongs to the developers. To drill this kind of capacity-and-commitment judgment, work through our PMP practice exams or, at the entry level, our CAPM practice exams.
Ready to take the next step in project management?
200,000+ Learners Trust Our Instructors
Frequently asked questions
What is sprint planning?
Sprint planning is the Scrum event that begins each sprint, where the whole Scrum team decides what work to take on and how to deliver it. It produces a sprint goal — the sprint's single purpose — and a sprint backlog, which is the selected product backlog items plus the plan to build them. It is the first of the Scrum events.
Who attends and who runs sprint planning?
The whole Scrum team attends: the product owner, the developers, and the Scrum Master, with stakeholders occasionally invited for advice. The Scrum Master facilitates the event but does not decide scope. Crucially, the developers — not the product owner or a manager — decide how much work the team commits to.
How long should sprint planning be?
Sprint planning is timeboxed to a maximum of eight hours for a one-month sprint, and proportionally less for shorter sprints — roughly four hours for a two-week sprint and about two hours for a one-week sprint. The timebox is a ceiling, not a target; well-prepared teams with a refined backlog often finish comfortably under it.
What are the outputs of sprint planning?
Sprint planning produces two outputs: the sprint goal and the sprint backlog. The sprint goal is a concise statement of what the sprint aims to achieve, and the sprint backlog is the set of selected product backlog items plus the plan to deliver them and the goal that ties them together.
What are the three topics of sprint planning?
The Scrum Guide frames sprint planning around three topics: why this sprint is valuable (defining the sprint goal), what can be done this sprint (selecting product backlog items that fit capacity), and how the chosen work will get done (breaking items into a plan). Working through all three produces the sprint backlog.
What is the difference between sprint planning and backlog refinement?
Backlog refinement is the ongoing activity of clarifying, estimating, and ordering product backlog items so they are ready to plan. Sprint planning is the single event at the start of the sprint where the team commits to a goal and selects the work. Refinement is preparation done throughout the sprint; planning is the commitment made once, up front.
Is sprint planning on the PMP exam?
Yes. The current PMP exam covers agile and hybrid approaches heavily, and iteration planning — the general term for sprint planning — appears in scenario questions. You are expected to know that it is timeboxed, produces a goal and a backlog, and belongs to the team, with the project manager facilitating rather than dictating the plan.
Is sprint planning on the CAPM exam?
Yes. The CAPM covers the Scrum events, including sprint planning, usually a little more directly than the PMP — often testing the timebox, the roles involved, or the outputs. Because the CAPM is scenario-based, you should also be ready to recognize when a team is overcommitting or planning without a clear goal.
What Is Scrum? Roles, Events & Artifacts [2026]
Scrum is a lightweight agile framework for complex work. Its theory, the 3 roles, 5 events, and 3 artifacts, scrum vs. agile, benefits, and PMP exam tips.
Scrum Master: Role, Responsibilities & Skills [2026]
A scrum master is a servant leader who helps a team work effectively. Responsibilities, scrum master vs. project manager, skills, becoming one, and exam tips.
Product Owner: Role, Responsibilities & Skills [2026]
The product owner maximizes a product's value and owns the backlog. Responsibilities, product owner vs. scrum master, skills, how to become one, and exam tips.
