Sprint planning: what it is, how to run it, agenda and templates (2026)

Sprint planning is the meeting that decides how the next two weeks of an entire team's work will be spent. No other meeting on the agile calendar has this much leverage per hour: a fuzzy sprint goal here costs ten days of scattered work, and an unprepared backlog costs two hours of reading tickets out loud to a captive audience.

Yet plenty of sprint plannings boil down to distributing tasks from a list. The team walks out with a sprint loaded to the brim, no goal that fits in a sentence, and the distinct feeling of having attended a ticket auction. Two weeks later, the sprint review confirms the inevitable, and the retrospective writes down "plan better" one more time.

This guide covers what sprint planning actually is and how to run one that produces a real plan: the 3 questions that structure it, how long it should take for each sprint length, a field-tested agenda for two-week sprints, the most common mistakes, templates ready to copy, and a way to keep decisions and acceptance criteria on record without appointing a note-taker.

⚠️ This article was independently compiled based on publicly available information and user feedback as of August 2026.

Table of Contents

1. What is sprint planning?
2. Planning, review, retro, refinement: the ceremonies at a glance
3. The 3 questions that structure sprint planning
4. How long should sprint planning take?
5. An agenda for a 2-week sprint
6. Common sprint planning mistakes
7. Sprint planning templates to copy
8. From planning to record, without a note-taker
9. FAQ
10. Conclusion

What is sprint planning?

Sprint planning is the meeting that kicks off each sprint: the full Scrum team defines what value it will deliver over the coming weeks, selects the backlog items that make it possible, and sketches a plan to get there. The output has a name of its own: the sprint backlog, which combines the sprint goal, the selected items, and the delivery plan.

Teams call it "sprint planning," "the planning meeting," or simply "planning." Whatever the label, it is one of the official events defined in the Scrum Guide, and it exists for one reason: a sprint that starts without a shared plan inherits somebody's implicit one.

Two boundaries sharpen the definition. First, sprint planning is not the place to discover the backlog. Candidate items should arrive already refined: understood, estimated, and carrying acceptance criteria. If the team reads tickets for the first time in planning, the meeting turns into an expensive refinement session with the entire payroll in the room. Second, the output is not a task list but a commitment to a goal. The difference shows when something breaks mid-sprint: a team with a goal renegotiates scope; a team with a task list simply runs late.

The whole Scrum team attends: the developers, who decide how much work fits and how it will be done; the product owner, who brings the purpose and the priorities; and the scrum master, who makes sure the meeting produces what it should. Others can be invited to advise on specific topics, but the call on how much fits in the sprint belongs to the people who will do the work.

Planning, review, retro, refinement: the ceremonies at a glance

Sprint planning is regularly confused with the other meetings in the cycle. The table sorts out who does what:

The relationship that matters most is refinement versus planning: refinement is the preparation, planning is the decision. Teams that suffer through endless plannings almost always have a refinement problem, not a planning problem. A widely used rule of thumb: when planning starts, the next two sprints' worth of backlog should be in a "ready to pick" state.

The 3 questions that structure sprint planning

The Scrum Guide organizes sprint planning around three topics, and they work as a natural script for the meeting:

1. Why is this sprint valuable?

The product owner proposes where the sprint could add the most value: what the product needs now, what stakeholders expect, what the team still needs to learn. From that proposal, the whole team crafts the sprint goal: one sentence that explains the purpose, not a sum of tickets. "A new user completes signup without help" is a goal; "finish the 12 tickets in the sprint" is not.

The goal must be finalized before planning ends. It is the compass for the rest of the sprint: when surprises hit, the team protects the goal and renegotiates everything else.

2. What can be done this sprint?

The developers select items from the product backlog, talking with the product owner to clarify scope and adjust the cut. This is where the cold numbers come in: the team's real capacity (vacations, holidays, support duty, meetings) and the track record of past sprints. Choosing how much fits is a hard prediction, which is exactly why the people who will execute the work make it, not the people requesting it.

The classic trap is planning for the ideal team in an interruption-free sprint. Experienced teams reserve an explicit buffer, often 15 to 20 percent, for the unplannable, and it costs them less than pretending it doesn't exist.

3. How will the work get done?

For the first items, the developers break the work down into small pieces, ideally a day or less each. There is no need to decompose the entire sprint in the meeting: enough to start with confidence is enough. This plan belongs to the developers alone; nobody else decides how they turn backlog into increment.

How long should sprint planning take?

The Scrum Guide sets the ceiling: a maximum of 8 hours for a one-month sprint, and proportionally less for shorter sprints. In practice, most teams run two-week sprints and finish planning in well under the theoretical maximum:

Two useful readings of this table. If your planning consistently wraps in 20 minutes, odds are nothing is being planned: a list is being accepted. If it always exhausts the timebox, the backlog is arriving unrefined or the team is doing full technical design in the meeting. Both extremes are symptoms, not styles.

An agenda for a 2-week sprint

A field-tested 2-hour structure, with the guide's three topics turned into clocked blocks:

1. Context and capacity (10 min). Last sprint's outcome in two sentences, any news that affects the plan, and real capacity: who is out, which holidays land, how much support work is expected.
2. Value proposal and sprint goal (25 min). The product owner explains the why. The team discusses and writes the goal in one sentence, visible to everyone. The meeting does not move on until the sentence exists.
3. Item selection (40 min). The team walks the refined candidates, clarifies scope questions and acceptance criteria, and cuts the sprint to capacity. Every item enters with a reason: it serves the goal, or it is an unavoidable commitment.
4. Execution plan (30 min). The first items get decomposed into day-sized tasks. Dependencies between people and on other teams get named, along with known risks.
5. Confirmation and close (15 min). The goal is re-read, the final cut is reviewed, and every open question leaves with an owner. The sprint backlog gets published where the whole team will see it daily.

The agenda scales down for one-week sprints (halve each block) and up for one-month sprints. What never changes is the order: first the why, then the what, finally the how. Reversing the order produces sprints that are technically coherent and strategically empty.

Common sprint planning mistakes

• Planning without a sprint goal. The most expensive mistake. Without one sentence explaining the purpose, the sprint is a bag of tickets and every surprise gets handled by panic instead of priority. The telltale sign: nobody on the team can recite the goal on the second Wednesday.
• Refining during planning. Reading tickets for the first time, estimating them, and debating design with the whole team present turns a 2-hour meeting into a 4-hour one. Refinement is a continuous activity during the sprint, not a block inside planning.
• Planning at 100 percent capacity. A sprint filled to the brim has no room for the urgent bug or the question that grows. The explicit buffer isn't pessimism: it is the difference between renegotiating and failing.
• The product owner decides how much fits. The pressure of "this has to go in" flips the roles. The product owner orders by value; how much fits is decided by those doing the work. Once that boundary breaks, estimates turn into negotiations.
• Confusing commitment with guarantee. The sprint backlog is an honest forecast, not a contract. Teams punished for "missing the sprint" quickly learn to pad estimates, and the whole planning exercise loses its informational value.
• Decisions that evaporate. "Wait, what did we decide about the migration?" asked on Thursday of week one is the classic symptom. The nuances of the cut, acceptance criteria clarified out loud, and dependencies spotted in discussion get said once and written nowhere.
• Skipping planning "because we already know what's next." A sprint that starts without a kickoff meeting inherits someone's implicit plan. It works until it doesn't, and then nobody remembers agreeing to anything.

Sprint planning templates to copy

1. Clocked agenda (paste into the invite)

# Sprint planning [Team] - Sprint [#] - [date] (2 h)
Prerequisite: candidates refined and estimated in the backlog

10 min - Context and capacity (absences, holidays, support duty)
25 min - Sprint goal (written together, 1 sentence)
40 min - Item selection and cut to capacity
30 min - Decomposition of first items and dependencies
15 min - Confirmation: goal + cut + open questions with owners

2. Minimal sprint backlog (the output document)

# Sprint [#] - [dates]
## Sprint goal
[1 sentence explaining the purpose]

## Capacity
Person-days available: [n] | Buffer for the unplanned: [%]

## Selected items
- [Item] - [initial owner] - acceptance criteria: [link or summary]
- ...

## Decisions and agreements from planning
- [Decision] - [context in 1 line]

## Dependencies and risks
- [Dependency] - depends on: [person/team] - needed by: [day]

## Not in this sprint (requested but cut)
- [Item] - reason for the cut

3. Product owner checklist (the day before)

[ ] Candidates for the next 2 sprints are refined and estimated
[ ] Every candidate has written acceptance criteria
[ ] The proposed sprint goal fits in one sentence
[ ] Last sprint's outcome is summarized in 2 sentences
[ ] Stakeholders with last-minute requests were heard (or invited to the review)

From planning to record, without a note-taker

Sprint planning produces more decisions per hour than almost any other meeting: the goal, the exact cut, acceptance criteria clarified out loud, dependencies, risks, what was left out and why. And nearly all of it is said while everyone stares at the board, not at a document. Appointing a note-taker doesn't fix it either: the person writing stops estimating and debating, in exactly the meeting where their judgment matters most.

This is where a real-time AI meeting assistant fits. SuperIntern is a botless desktop app (Mac and Windows) that captures the meeting straight from device audio: no ghost participant joins the call, and it works the same in Zoom, Google Meet, Microsoft Teams, Webex, or in the room around a physical board.

In a planning meeting, that translates into a concrete flow:

• Hand AI Canvas the structure of your sprint backlog. Describe it once in plain language: "Record the sprint goal as a verbatim quote, selected items as a table with owner and criteria, decisions as a list, and anything cut with its reason." Over the 2 hours, the live note fills itself in exactly that shape.

• Ask the AI chat without stopping the meeting. "What did we estimate for this in Tuesday's refinement?" or "what did we decide about the migration last planning?": the chat also queries your past meetings, so the answer arrives without digging through old notes or halting the discussion.

• Acceptance criteria said out loud end up in writing. The product owner's verbal clarification of what "done" means for a specific item is exactly what gets disputed at the review. With a transcript, the exact sentence is searchable; without one, it gets reconstructed from memory.
• Whoever missed it catches up without ceremony. The summary is ready when the meeting ends: the teammate on vacation or the curious stakeholder reads the goal and the cut in two minutes.
• Multilingual teams plan in their own language. SuperIntern translates in real time across 50+ languages, and each person can get the summary in theirs, which helps when planning spans Austin, Mexico City, and Berlin.

An honest note: SuperIntern is a desktop app for live meetings. It doesn't manage your backlog or replace Jira or Linear; its territory is the planning conversation itself, the one where decisions currently evaporate. There is a free plan, so trying it in your next planning costs nothing.

FAQ

What is sprint planning, in short?

The meeting that starts each sprint: the team defines a goal, selects the backlog items it can deliver, and sketches the plan to get there. The output is the sprint backlog: goal, selected items, and plan.

How long does sprint planning take?

A maximum of 8 hours for a one-month sprint, proportionally less for shorter ones. For the two-week sprint, the most common format, most teams finish in 1.5 to 2 hours if the backlog arrives refined.

Who attends sprint planning?

The full Scrum team: developers, product owner, and scrum master. Specialists can be invited to advise on specific topics. The decision on how much work fits belongs exclusively to the developers.

What's the difference between sprint planning and backlog refinement?

Refinement prepares: it clarifies, splits, and estimates backlog items continuously during the sprint. Planning decides: it picks among prepared items and builds the plan. If planning is spent refining, you are paying for preparation at full-team meeting prices.

What is a sprint goal and why does it matter so much?

One sentence explaining the sprint's purpose, written by the whole team during planning. It matters because it is the renegotiation criterion: when a surprise lands, the team protects the goal and adjusts the rest, instead of blindly defending a ticket list.

Can you run sprint planning without story points?

Yes. Points are a forecasting tool, not a Scrum requirement. Teams estimate in T-shirt sizes, ideal days, or by counting similarly sized items. What's non-negotiable is that the people doing the work make the forecast, informed by past sprints.

How do you run sprint planning with a remote or distributed team?

Same as in person, with three adjustments: the shared board on screen replaces the wall, the sprint goal lives in a document visible from minute one, and the record of decisions is automated, because remote teams have no hallway in which to reconstruct what nobody wrote down.

Conclusion

A sprint planning isn't measured by walking out with a full calendar, but by three outcomes: a goal that fits in one sentence, a backlog cut chosen by the people doing the work, and a plan sufficient to start tomorrow with confidence. The guide's 3 questions (why, what, how) are the script; the timebox and the capacity buffer are the guardrails.

And as in every meeting where a lot gets decided in little time, memory is the weak link: the goal gets remembered, but criteria clarified out loud and the reasons behind the cut evaporate before the first daily. That record no longer needs a note-taker: a botless AI assistant writes the live note in whatever structure the team asks for, while the team does the one thing only the team can do: decide the sprint well.

Try SuperIntern Free : no bots in your planning, the goal and agreements captured the moment they're said, and a summary ready to share when you're done.