Sprint Planning: Agenda, Capacity, and Example

There’s a reason weather forecasts tell you there’s a 70% chance of rain instead of promising it’ll rain at exactly 3 PM. They use the information available, account for uncertainty, and update as new data comes in. You can still plan your afternoon around them, as long as you don’t mistake the forecast for a guarantee.

Sprint planning works on a similar principle. A Scrum Team has a product backlog, an estimate of its available capacity, and a goal it wants to achieve. But some work details only become clear as the sprint progresses. Planning every hour in advance leaves little room for those discoveries, while going in without a shared direction makes it harder to decide what deserves attention.

The aim is to agree on a valuable outcome and forecast how much work the team can complete to achieve it. From there, the team can adapt its plan as it learns more without losing sight of the sprint goal.

This guide covers backlog preparation, a timed planning agenda, practical capacity calculations, and a worked example that shows how to adjust the plan during the sprint.

TL;DR

Sprint planning brings the Scrum Team together to agree on one sprint goal, select backlog items, and establish an initial delivery plan:

Prepare by refining upcoming work and checking availability, unfinished items, dependencies, and the Definition of Done
Base the forecast on actual capacity and past performance, accounting for leave, meetings, support duties, and uncertainty without counting commitments twice
Leave planning with a shared sprint backlog, then adjust the delivery plan as the team learns more while protecting the sprint goal
Use the two-hour sample agenda and worked capacity example as starting points, adapting them to the team’s needs

Sprint Planning: How to Run a Meeting That Survives the Sprint

What Is Sprint Planning?

Sprint planning is a Scrum event held at the beginning of each sprint to agree on what the team wants to achieve and how it’ll approach the work. It brings the entire Scrum Team together, including the Product Owner, Scrum Master, and developers. Other specialists, such as security engineers or customer-facing leads, can also join when their input would help the team make informed decisions.

According to the Scrum Guide, every planning session should produce three things: a sprint goal that explains the value of the work, a selection of product backlog items that support that goal, and an initial plan for delivering them. Together, these form the sprint backlog, which developers continue to update as the sprint progresses.

The Scrum Guide sets a maximum of eight hours for a one-month sprint, and shorter sprints usually need less. With a well-refined backlog, the agenda below fits in two.

If you’re unfamiliar with some of these terms, our glossary covers the basics of agile and Scrum.

The Three Questions Sprint Planning Answers

Every sprint planning session revolves around three questions:

Why is this sprint valuable?
What can we accomplish?
And how will we get the work done?

The Scrum Guide organizes planning around these questions, starting with the value you want to deliver. Once everyone’s clear on that, it’s easier to decide which backlog items deserve attention and how much work your team can reasonably take on.

Question	Who leads	Output	Example for a 2-week sprint
Why is this sprint valuable?	Product Owner proposes; whole team agrees	Sprint goal	New customers can pay by card at checkout without contacting sales
What can be done this sprint?	Developers select, with the Product Owner	Selected backlog items	Card payment form, payment provider integration, receipt email, error handling
How will the chosen work get done?	Developers	Initial task plan	Items split into tasks, often a day or less each, with initial responsibilities agreed upon

Why the sprint matters

The sprint goal gives the team something to work toward and helps stakeholders understand what to expect. Agree on this goal with your Scrum Team before the planning session ends.

Describe an outcome people can recognize, such as “Trial users can invite teammates,” rather than a workload target like “Finish 34 story points.” If an unexpected issue comes up, the goal helps the team decide which work to adjust while preserving the intended outcome.

What the team can finish this sprint

Once you’ve agreed on the goal, it’s time to work out what the team can realistically deliver.

Developers select backlog items in discussion with the Product Owner while considering available capacity, past performance, and the Definition of Done. This is also the right moment to review any existing commitments that could affect how much time the team has for sprint work.

Many teams use story points to compare the relative effort and complexity of backlog items. A Fibonacci scale can help structure those discussions, particularly when the effort involved is unclear.

If you’re new to story points or want to see how they’re used in practice, here’s a walkthrough of the estimation process.

How the team will do the work

With the backlog items selected, developers work out how they’ll turn them into a finished product increment that meets the Definition of Done. The Scrum Guide suggests breaking larger items into smaller pieces of work, often sized to take a day or less.

That doesn’t mean you need to map out every hour of the sprint. The first few days may need a more detailed plan, while later tasks can remain open to adjustment as new details emerge. Treating early estimates as firm commitments can pressure the team to meet the original numbers, even if the scope changes midway.

As Dave West, CEO of Scrum.org, explains:

A forecast used to defend a date invites exactly the behavior that erodes trust, like padding estimates, hiding risk, or quietly redefining ‘done’ to hit a number.

Dave West

Backlog refinement gives your team a clearer understanding of upcoming work before it’s time to decide what belongs in the next sprint. Sprint planning builds on that preparation to agree on a goal, select backlog items, and establish an initial delivery plan.

The two activities serve different purposes within Scrum:

Dimension	Backlog refinement	Sprint planning
Purpose	Clarify, split, and estimate upcoming backlog items	Set the sprint goal, select work, and plan delivery
Timing	Ongoing throughout the sprint	At the start of each sprint
Scrum status	An ongoing activity	A formal Scrum event with a timebox
Who participates	Product Owner and relevant developers	The whole Scrum Team
Output	Backlog items with clearer details, estimates, and scope	The sprint backlog: the sprint goal, selected items, and delivery plan

Keep enough upcoming backlog items refined so the team has clear choices during sprint planning. How much preparation is useful depends on how quickly priorities change and how much uncertainty remains. Items further down the backlog can stay less detailed until they move closer to selection.

Also Read: For more guidance, see our articles on backlog grooming and keeping your product backlog organized and prioritized.

How to Prepare for Sprint Planning

A few days beforehand, check that the backlog is in good shape and everyone has the information they’ll need to make decisions. That way, you can spend the session discussing what to deliver and how to approach it without having to resolve every requirement from scratch.

Here’s a checklist to work through before your next sprint:

Draft a sprint goal: Have the Product Owner propose an outcome that supports the broader Product Goal, giving the team concrete points to discuss
Review the product backlog: Make sure the highest-priority items are ordered, understood, and estimated where needed
Check team availability: Ask developers to share planned leave, support rotations, and other commitments that could affect their capacity
Revisit unfinished work: Review carryover from the previous sprint and any improvements identified during the retrospective
Identify dependencies: Flag work that requires another team’s input or approval and clarify who’ll coordinate it
Review the Definition of Done: Make sure everyone understands the quality standards each completed backlog item must meet

If you’re scheduling the sprint retrospective and planning session close together, leave enough time for a proper discussion in both. The retrospective’s findings should inform the next sprint’s plan, so make sure that neither meeting feels rushed.

Sprint Planning Agenda: A Timed Example for a 2-Week Sprint

For a two-week sprint, start with a two-hour planning session, particularly when the backlog has already been refined. Plan for extra time if the work involves complex dependencies or several decisions that require discussion.

You can adapt this sample agenda to your team’s needs.

Time	Agenda item	Who leads	Expected output
0:00–0:10	Review the previous sprint’s outcome, unfinished work, and retrospective actions	Scrum Master facilitates	Shared understanding of what needs attention
0:10–0:30	Discuss the Product Owner’s proposed sprint goal and agree on the desired outcome	Whole Scrum Team	A draft sprint goal everyone understands
0:30–0:45	Confirm team availability and review any capacity constraints	Developers	A realistic picture of available capacity
0:45–1:15	Select backlog items that support the goal	Developers, with the Product Owner	A selection of work the team believes it can complete
1:15–1:45	Break down selected items and discuss the delivery approach	Developers	An initial plan for completing the work
1:45–2:00	Review dependencies, check confidence, and finalize the sprint goal	Whole Scrum Team	An agreed sprint goal and a sprint backlog ready for the team to use

Before wrapping up, you can use a quick confidence check such as Fist of Five, where everyone rates their confidence in the plan from zero to five fingers. If someone gives a low score, ask what’s causing the concern. It could reveal an unresolved dependency, an overly ambitious forecast, or a requirement that needs more discussion.

The aim is to surface concerns while there’s still time to adjust the plan.

How to Run Sprint Planning in 6 Steps

Once you’ve prepared the backlog and confirmed who’s attending, start the planning session. The goal here is to help the team turn its priorities and available capacity into a plan it feels confident it can deliver.

Step 1: Review previous work and agree on a sprint goal

Start with a brief look at what was completed, what remains unfinished, and whether any retrospective actions should influence the next sprint. Focus on anything that could change the team’s priorities or approach, rather than revisiting the entire sprint review.

Then have the Product Owner introduce the proposed sprint goal and explain how it supports the broader Product Goal. Give developers room to question its scope, raise dependencies, and suggest adjustments.

For example, if the goal is to let customers complete checkout without contacting sales, agree on what a successful checkout looks like. Does it include payment confirmation and error handling? Is automated receipt delivery essential for the first release?

These discussions help you define an outcome the team can work toward. The wording may evolve as backlog items are selected, but everyone should agree on the final goal before planning ends.

Step 2: Calculate the team’s available capacity

Before selecting work, establish how much time your developers can realistically dedicate to the sprint.

Start with the number of working days and each person’s expected availability. Then account for planned leave, Scrum events, support responsibilities, and other known commitments. If a developer spends half their week handling production issues, those hours are already committed and unavailable for planned sprint work.

A simple calculation is: Available capacity = Total working hours − Known commitments

For instance, a developer with 80 working hours over two weeks might have 8 hours of leave, 10 hours of meetings, and 12 hours of support duty. That leaves 50 hours before accounting for any additional uncertainty.

Compare this figure with the team’s past performance. Velocity shows how much work the team completed in previous sprints, while capacity reflects the time available for this sprint.

Pro Tip: If you’re using hours for capacity planning, keep them separate from story points. The two measure different things, and there’s no universal conversion between them.

Step 3: Reassess unfinished work from the previous sprint

Unfinished backlog items deserve another look before you add them to the new sprint. An item that was important two weeks ago may have changed in priority, or the team may have learned something that affects how much work remains.

Review each item with the Product Owner and consider:

Relevance: Does it still support the proposed sprint goal or another important product priority?
Remaining effort: How much work is left now that part of the item has been completed?
Dependencies: Is anything preventing the team from making progress?
Priority: Should this item come before newly refined backlog items?

For work that still belongs in the sprint, use the remaining effort to judge how much capacity it will need. A half-finished item may require less work than its original estimate, but it still counts as unfinished until it meets the Definition of Done.

Step 4: Select backlog items that support the goal

With your capacity and outstanding work understood, developers can select the product backlog items they believe they’ll be able to complete.

Start with items that directly support the sprint goal. Discuss their acceptance criteria, technical dependencies, and any uncertainties that could affect delivery. If an item is too large or unclear, consider splitting it into smaller pieces that can deliver value within the sprint.

You may also have room for maintenance or other product priorities, but check whether taking on that work could put the main goal at risk.

How much capacity should you reserve?

Planning only 80% of available capacity can be a reasonable starting point for teams that regularly handle unexpected support work, but Scrum doesn’t prescribe a fixed percentage.

If your team has experienced frequent interruptions, you could reserve 10–20% of its adjusted capacity and compare that allowance with what was needed during previous sprints. A team with stable work and few interruptions may need less. One supporting a live service with frequent incidents may need more.

Avoid counting the same commitment twice. If scheduled support hours were already deducted in Step 2, the additional buffer should cover uncertainty beyond that known workload. Use the resulting capacity as a guide for discussion, not a target to meet.

Remember: A sprint with spare capacity isn’t necessarily underplanned. If you’ve selected enough work to achieve the sprint goal, filling the remaining hours with unrelated tasks can create competing priorities. Sometimes a smaller forecast is more realistic, especially when the selected work carries significant uncertainty.

Step 5: Break down the work and check dependencies

Once you’ve selected the backlog items, developers can work through how they’ll deliver them. This can involve breaking larger items into development, testing, integration, and review tasks.

Look closely at the order of work. If the checkout interface depends on a payment provider integration, the team should understand when that integration needs to be ready. If another team must approve a security change, clarify how and when that decision will happen.

Plan the immediate work in more detail, leaving later tasks open for further discussion. The Scrum Guide suggests decomposing selected items into smaller work items, typically sized to a day or less, but developers decide how to organize and distribute the work.

Check that the plan accounts for the Definition of Done, including essential testing and integration work. If a dependency could prevent delivery, revisit the selected items or adjust the delivery approach before finalizing the plan.

Record the sprint goal, selected product backlog items, and initial delivery plan somewhere the team can access and update. Together, these should make clear what the team aims to achieve and which work needs attention next.

Before closing the meeting, confirm that the goal is agreed upon and give everyone a chance to raise any remaining forecast concerns. If an important dependency or capacity issue is unresolved, discuss what needs to change before the team begins.

During the sprint, the Daily Scrum gives developers an opportunity to inspect progress toward the goal and adjust the sprint backlog. A burndown or burnup chart can help show changes in progress, while the underlying tasks provide detail. If new information affects the selected scope, developers can discuss adjustments with the Product Owner without putting the sprint goal at risk.

Sprint Planning Example: A Team with 6 Developers

Let’s see how these decisions work in practice.

Imagine you’re planning a two-week sprint for a B2B billing product. Your team has six developers and a proposed sprint goal: “New customers can pay by card at checkout without contacting sales.”

Before selecting backlog items, you need to know how much time the team has available. For this example, assume each developer has six potential hours of focused project work per day, before deducting planned Scrum events and other commitments.

This is how the capacity calculation works across 10 working days:

Capacity calculation	Hours
Base capacity: 6 developers × 10 days × 6 hours	360
Planned leave: 1 developer away for 2 days	−12
On-call duty: 1 developer at 50% availability	−30
Scrum events: 8 hours per developer	−48
Available capacity	270
Reserve 20% for unexpected work	−54
Capacity available for planned work	216

You’ve now got 216 hours for planned work after setting aside an illustrative 20% buffer. In practice, you’d choose that allowance based on how much unplanned work interrupted previous sprints.

Choose the work that supports the sprint goal

With capacity established, the developers review the backlog items related to checkout with the Product Owner.

Here’s an illustrative selection based on their initial task-level effort estimates:

Backlog item	Estimated effort
Build the card payment form	48 hours
Integrate the payment provider	88 hours
Handle failed payments and validation errors	50 hours
Add payment confirmation and receipt delivery	24 hours
Total planned work	210 hours

These estimates leave 6 hours within the planned-work allowance, plus the 54-hour buffer for unexpected work. The team also has a reporting dashboard improvement in the product backlog. Although it’s valuable, it doesn’t contribute directly to the checkout goal. The Product Owner and developers agree to leave it for a future sprint.

Adjust the plan when something changes

On day six, the payment provider introduces an API change that breaks part of the integration. The developers investigate and estimate the additional work needed.

Rather than continuing with the original task order, they discuss the impact with the Product Owner. If the fix fits within the remaining capacity, they can prioritize it and defer optional receipt styling or another lower-priority task. Payment confirmation and other essential work still need to meet the Definition of Done.

If the fix is larger than expected, they’ll need to reassess the remaining scope and whether the sprint goal is still achievable.

The team may finish with fewer completed backlog items than originally forecast. But if customers can complete checkout as intended and the work meets the Definition of Done, it has achieved the sprint goal.

Sprint goal examples for other teams

You can apply the same planning approach to work outside software development, although Scrum itself is a specific framework with defined accountabilities and events.

For example, a marketing team might set a goal such as “Publish the webinar landing page and enable visitors to register without manual assistance.” An operations team could aim for “Ensure every employee in the next onboarding cohort has the equipment and system access needed on their first day.”

Both goals describe outcomes that can guide the team’s decisions throughout the sprint. The backlog items and delivery plans will differ, but the team still needs to consider its capacity and agree on what successful delivery looks like.

Common Sprint Planning Mistakes and How to Fix Them

Sprint planning can run into problems when teams use story points to judge individual performance, bring unclear backlog items into the meeting, assign work too rigidly, or overlook testing requirements and external dependencies.

A few adjustments can help you catch these issues before they affect delivery.

Mistake	Why it causes problems	How to fix it
Using story points to measure individual performance	Comparing developers by completed points can encourage inflated estimates or avoidance of complex work.	Keep story points focused on team-level forecasting. Review completed work across several sprints and discuss estimate changes during refinement. Assess individual performance through code quality, collaboration, and outcomes.
Bringing unclear backlog items into planning	Missing acceptance criteria or unanswered technical questions turn planning into a discussion about what to build, leaving less time to plan delivery.	Resolve questions during backlog refinement so developers can make a reasonable forecast. If uncertainty remains, consider a smaller, better-understood piece of work. Aim for enough clarity to make a decision, rather than perfect specifications.
Assigning every task to someone before work begins	Fixed assignments make it harder to adapt when priorities shift or one developer finishes early while another needs help.	Let developers organize the work. Agree on immediate responsibilities and specialist input, then allow teammates to pick up, pair on, or redistribute tasks during the sprint. Keep work visible to the whole team.
Leaving external dependencies unresolved	Missing API credentials, security reviews, or another team’s deliverables can leave the team waiting on work it can’t control.	Before finalizing the sprint backlog, identify the required input, who will coordinate it, and when it’s expected. If a critical dependency remains uncertain, consider an alternative item or a smaller scope the team can deliver independently.

If the same problems keep appearing across multiple sprints, bring them into the sprint retrospective and agree on a change you can test during the next sprint. These sprint retrospective templates can help you capture observations and follow-up actions.

At the end of the sprint, use the sprint review meeting to inspect the completed increment with stakeholders and discuss what the team should tackle next.

How to Run Sprint Planning in ClickUp

Sprint planning takes more effort when tasks, capacity estimates, and planning decisions are scattered across different tools. ClickUp brings that information together, so the team can review work alongside capacity and revisit planning decisions when the plan changes.

Start with the ClickUp Agile Sprint Planning Template. Its backlog, development status, and resource views help you review upcoming work and prepare for the planning discussion.

Prepare sprint planning with the ClickUp Agile Sprint Planning Template using backlog and resource views

Here’s how to work through the key decisions:

Make upcoming work easier to assess: Keep requirements, acceptance criteria, priorities, and dependencies in a backlog list of ClickUp Tasks. These details help developers discuss scope and estimate effort before selecting work. Add the chosen tasks to the sprint once the team has agreed on the plan
Set a consistent planning window: Configure the sprint duration and start dates in ClickUp Sprints. Use Sprint Points or Time Estimates to assess effort and help the team judge how much work it can take on

ClickUp Sprints Reporting with Dashboard: Sprint Planning — Track sprint velocity and task completion across cycles with ClickUp Sprints

Check whether the work fits: Compare assigned work with each person’s capacity in ClickUp Workload View. Review uneven workloads and discuss any changes before finalizing the forecast
Keep the agenda and decisions close to the work: Use ClickUp Docs for the timed agenda, proposed sprint goal, and links to relevant tasks. Record scope decisions and unresolved questions during the session so the team can revisit them as work progresses
Capture the planning discussion: ClickUp AI Notetaker can capture meetings in Zoom, Google Meet, Microsoft Teams, or SyncUps and save a summary, key decisions, and action items in a Doc. Review the notes, then update sprint tasks with agreed follow-ups
Use progress data to guide discussions: Add Sprint Burndown or Burnup cards to ClickUp Dashboards to review completed work and remaining effort. When progress differs from the plan, review the relevant tasks for delays or scope changes that need attention

Before the next planning session, ask Brain², “What unresolved dependencies came up in our last sprint planning session?” Brain can retrieve context from captured meeting notes. Check those details against the current tasks before using them to inform the next forecast.

ClickUp Brain AI cards — Use AI Cards in ClickUp Dashboards to summarize recent activity on your tasks

ClickUp pricing

Free Forever

Free Free

Key features

60 MB Storage

Unlimited Tasks & Subtasks

Unlimited Free Members

Collaborative Docs

Kanban Boards

Calendar View

Core

$9 $12

user / mo · billed yearly

Everything in Free Forever, plus:

Custom Fields & Task Types

Unlimited Storage and Spaces

Unlimited Forms

Unlimited Gantt Charts

Unlimited ClickUp Chat

1K Automations

Business

Popular

$17 $25

user / mo · billed yearly

Everything in Core, plus:

Advanced Dashboards

Webhooks & Automation Integrations

10K Automations

Resource Management

Google SSO + SMS 2FA

Private Views

Enterprise

Custom Custom

Talk to our team

Contact Sales

Everything in Business, plus:

White Labeling

1M Automations

Unlimited Custom Roles

Enterprise Permissions & Governance

Advanced SSO, SCIM, SAML

Audit Logs & Session Management

MAX

The full Max AI engine plus every Enterprise-grade control.

$100 $120

user / mo · billed yearly

Contact sales

Everything in Enterprise, plus:

ClickUp Brain²

Maximum Premium Model Usage

Custom Skills

Context Engine & Auto-Memory

Max AI Engine

Unlimited AI Fields

Unlimited Notetaker

Unlimited AI Image Generation

Everything in Enterprise:

White Labeling

1M Automations

Audit Logs & Session Management

See more features

* Prices when billed annually

Best for: Scrum teams managing multiple sprints, shared dependencies, and changing workloads that need backlog management, capacity planning, and progress reporting in one workspace. It’s also a good fit for teams coordinating sprint work with broader product or business projects.

Skip it if: Your team only needs a basic Scrum board with a small backlog and minimal reporting. ClickUp’s flexibility comes with setup decisions around sprint settings, views, and fields. Some advanced sprint reporting and automation features also require higher-tier plans, which may be unnecessary for a straightforward workflow.

How Much Should You Plan Before a Sprint Begins?

A sprint planning session should leave the team with enough clarity to start work.

The timed agenda and capacity example above provide a starting point. Adapt them to the team’s workload, then compare the forecast with completed work and interruptions to improve the next one.

In ClickUp, you can link planning notes to sprint tasks and update the sprint backlog as work changes. The team can refer back to the agreed plan when deciding what to adjust.

Plan your next sprint with ClickUp

Frequently Asked Questions About Sprint Planning

What’s the difference between sprint planning and release planning?

Sprint planning focuses on what your team aims to accomplish during one sprint and how it will deliver that work. Release planning considers a longer horizon, like which features could be available across several sprints and when users might receive them. Release forecasts can change as teams learn more, while each sprint goal guides the work within its current sprint.

Do you need a Definition of Ready for sprint planning?

No. Scrum doesn’t require a formal Definition of Ready. Some teams use one to set shared expectations for backlog items before selection, such as clear requirements, manageable scope, and known dependencies. Keep these criteria lightweight enough to support discussion without preventing the team from refining items when needed.

Can a sprint be canceled after planning?

Yes. Only the Product Owner can cancel a sprint, and cancellation is an option when the sprint goal becomes obsolete, perhaps because business priorities or market conditions have changed significantly. A difficult task or an inaccurate estimate alone doesn’t necessarily justify cancellation.

What is the difference between a sprint and agile?

Agile is a broader approach to managing work based on the values and principles of the Agile Manifesto. A sprint is a fixed period of one month or less within the Scrum framework, during which a team works toward a sprint goal and creates a usable increment. You can follow Agile principles without using sprints. Kanban, for example, supports a continuous flow of work without requiring fixed-length iterations.

Can one sprint have multiple sprint goals?

Scrum defines one sprint goal as the sprint’s single objective. You can select backlog items that support other priorities, as long as they don’t put that goal at risk. If your team regularly needs several unrelated goals, discuss whether the work supports a broader shared outcome or whether you need to resolve competing priorities before planning.

Should you estimate bugs in story points during sprint planning?

Story points are optional in Scrum, including for bugs. Teams that estimate bugs should agree on when and why to do so. Known defects can be assessed during planning, while bugs discovered during development may fall within the work already needed to meet the Definition of Done. Avoid counting the same effort twice.

Everything you need to stay organized and get work done.

Contact Sales

Sprint Planning: How to Run a Meeting That Survives the Sprint

What Is Sprint Planning?