Sprint planning is the shortest Scrum ceremony, but it has the most downstream consequences. A well-run sprint planning meeting takes 90 minutes and creates two weeks of clear, focused execution. A poorly run one produces a sprint backlog nobody trusts, a team that overcommits, and a sprint review where half the stories are carried over.
The numbers are significant: 87% of Agile teams use Scrum as their primary framework. Sprint planning is the ceremony that operationalises all the preparation work — backlog refinement, capacity calculation, priority decisions — into an executable plan. When it works, the whole team leaves the room aligned. When it doesn't, those two weeks are spent managing confusion, renegotiating scope, and patching over decisions that should have been made on day one.
The core tension in sprint planning is structural. It requires product clarity from the Product Owner, technical realism from developers, and process discipline from the Scrum Master. When any one of those is missing, the sprint starts on a fragile foundation. A Product Owner who hasn't refined the backlog turns planning into a first-read session. Developers who commit under management pressure overcommit. A Scrum Master who lets the meeting drift produces a sprint backlog that nobody actually believes in.
This guide is a complete, repeatable sprint planning checklist covering pre-sprint preparation, the planning meeting itself, and post-planning actions — with the specific inputs, outputs, and quality checks Scrum teams need to run consistent, high-confidence sprints. Written for Scrum Masters, engineering leads, and product managers who want to tighten their sprint planning process, not learn what Scrum is.
What Is Sprint Planning?
Sprint planning is the Scrum ceremony that initiates each sprint. It is a time-boxed collaborative meeting where the Scrum Team determines what work will be accomplished in the upcoming sprint and how that work will be done.
The 2020 Scrum Guide is explicit about the structure: sprint planning is the first event of the Sprint. The entire Scrum Team attends. The timebox is maximum two hours per week of sprint length — four hours for a two-week sprint, eight hours for a one-month sprint. There are no optional attendees and no justifiable reason to skip it.
Sprint planning produces two outputs:
- A sprint goal — the single objective for the sprint that communicates what the team is trying to achieve and why it matters
- A sprint backlog — the selected Product Backlog items plus the plan for delivering them during the sprint
Why sprint planning matters beyond process compliance:
- It creates shared commitment and clarity — every team member leaves knowing what the sprint is for and what their role in it is
- It forces the team to reality-check estimates against actual capacity, surfacing overcommitment before it becomes a mid-sprint crisis
- It surfaces dependencies and blockers before execution begins, not after someone discovers them on day six
- It produces the sprint goal that guides scope decisions when conflicts arise mid-sprint — which they always do
Sprint planning sits at a specific point in the Scrum framework. It follows backlog refinement, which should have happened continuously throughout the preceding sprint, and precedes the first daily standup of the new sprint. Teams with strong sprint planning ceremonies target 85–95% sprint commitment accuracy as a healthy operating range.
The Three Questions of Sprint Planning
The 2020 Scrum Guide defines sprint planning around three topics. Many teams conflate the first two, or skip the first entirely. Distinguishing all three — and addressing them in order — produces sharper planning and better sprint outcomes.
Topic 1: WHY — The Sprint Goal
Why is this sprint valuable? The Product Owner proposes how the sprint can increase the product's value. The Scrum Team then collaborates to define a sprint goal that communicates the value of the sprint to stakeholders. This happens first, before selecting any items. A sprint without a goal is a list of tasks. A sprint with a clear goal is a coordinated effort toward a defined outcome.
Topic 2: WHAT — The Sprint Backlog Selection
What can be done this sprint? Developers select items from the Product Backlog to include in the sprint backlog. Selection is informed by the sprint goal, the team's velocity, current capacity, and the Definition of Done. The Product Owner can clarify items and negotiate priorities; only developers estimate effort and select the work they believe they can complete. This is not a negotiation between management and engineering — it is developers assessing what is achievable.
Topic 3: HOW — The Implementation Plan
How will the selected work get done? For each sprint backlog item, developers plan the work needed to create an increment that meets the Definition of Done. This includes breaking stories into tasks, identifying technical approaches, and surfacing implementation dependencies. Tasks should generally be small enough to complete in a day or less — if a task takes three days, it will not be visible at standup and cannot be tracked effectively.
A common planning failure is spending 80% of the meeting on "WHAT" while skipping "WHY" entirely. Teams without a sprint goal make inconsistent scope decisions mid-sprint and struggle to communicate sprint value to stakeholders. Address the sprint goal first, every time.
Roles and Responsibilities
Sprint planning has three participants. Each has a defined role. Conflating them — or allowing one role to absorb another's responsibilities — is one of the most common sources of dysfunctional planning.
| Role | Sprint Planning Responsibilities |
|---|---|
| Product Owner | Prioritised, refined backlog ready before the meeting; proposes sprint goal; clarifies acceptance criteria when asked; negotiates scope but does not dictate estimates or implementation approach |
| Scrum Master | Facilitates the meeting; enforces timebox; ensures the team addresses all three planning topics; removes impediments; helps the team understand the Scrum framework during planning |
| Developers | Select sprint backlog items; provide effort estimates; break stories into tasks; surface dependencies and technical blockers; commit only to what they genuinely believe is achievable |
One point worth making explicit: only developers estimate. The Product Owner and Scrum Master do not assign effort estimates to backlog items or set the sprint commitment. This is a common anti-pattern in organisations where managers attend sprint planning and pressure teams toward larger commitments. The moment management starts setting estimates, the commitment loses validity as a planning tool — developers will adjust their estimates to match expectations rather than reality.
Stakeholders — product management, business owners, customers — do not attend sprint planning. Their input belongs in backlog refinement and sprint review, not the planning ceremony. Stakeholder presence in sprint planning introduces social pressure that distorts estimates and commitment decisions.
Sprint Planning Inputs
Five inputs are required before sprint planning can run effectively. If any are missing, sprint planning should be paused until they are available — starting without them produces a sprint backlog that is unreliable from day one.
Refined Product Backlog
The top items must be estimated, have written acceptance criteria, and be understood by the whole team. Items without acceptance criteria should not be selected into the sprint — they cannot be verified as complete. The standard: the top 2–3 sprints' worth of backlog should be refined at all times, so planning always has a ready pool of committable items to draw from.
Team Capacity
Available working days per person minus planned absences, ceremonies, and non-sprint work (support rotation, on-call, meetings). Expressed in hours or story points. Must be calculated before the meeting, not during it. A team that discovers its capacity mid-planning loses 15 minutes to arithmetic and starts the conversation from a number nobody verified.
Historical Velocity
Rolling average of story points completed over the last 3–5 sprints. The primary guide for how much to commit. Should be visible to the team before and during planning. New teams without velocity history use 80% of their first sprint's completion as the initial guide, then recalibrate as the rolling average stabilises.
Sprint Goal Proposal
The Product Owner should arrive with a draft sprint goal — the "why" that frames the backlog items being considered. This is a proposal to be refined with the team, not a unilateral decision. Arriving without a draft sprint goal forces the team to construct one from scratch during the meeting, which consumes time and often produces vague goals that provide no decision-making value.
Definition of Done
The shared team agreement on what "complete" means for any increment. Must be understood by all team members before any story is accepted into the sprint. If the Definition of Done has been updated recently — following a retrospective change, for example — confirm all team members understand the changes before planning begins.
Skipping backlog refinement and expecting sprint planning to do the refinement work is the #1 cause of overlong planning meetings. If you're regularly spending 3+ hours in a two-week sprint planning, your backlog refinement process needs fixing — not your planning meeting facilitation.
Calculating Team Capacity
Capacity calculation is the most frequently skipped step in sprint planning preparation and the most consequential one. Teams that plan without a calculated capacity number are making commitments against an unknown ceiling — which is why they consistently overcommit.
Identify sprint length and working days
Count the calendar working days in the sprint, excluding weekends and any public holidays. For a standard two-week sprint starting Monday, that is typically 10 working days. If the sprint straddles a bank holiday, it is 9. Do this before anything else — the working day count is the foundation of all subsequent calculations.
Calculate individual availability
For each team member: working days × available hours per day (typically 6–7 productive hours; not 8). Then subtract: planned leave (holidays, PTO), recurring non-sprint commitments (support rotation, other team duties), and ceremony time (planning, daily standups, review, retro — roughly 1–2 hours per week per person for a standard Scrum ceremony set).
Apply a capacity buffer
Deduct 20% for unplanned interruptions — production issues, unexpected meetings, tool problems, a colleague asking for help. Never plan to 100% capacity. Teams consistently operating above 85% capacity accumulate technical debt, miss sprint goals, and produce lower quality work. The buffer is not slack; it is the realistic allowance for how work actually happens.
Convert to story points if using points
If your team plans in story points rather than hours, convert available capacity using your team's reference velocity. Some teams plan in hours only; others plan entirely in story points. The method matters less than consistency — use the same approach every sprint so that capacity comparisons across sprints are meaningful.
A worked example for a three-developer team in a standard two-week sprint:
| Team Member | Working Days | Deductions | Available Days | Available Hours |
|---|---|---|---|---|
| Dev 1 | 10 | 1 day PTO, ceremonies | 8.5 | ~51 |
| Dev 2 | 10 | Ceremonies only | 9 | ~54 |
| Dev 3 | 10 | 2 days support rotation | 7 | ~42 |
| Total | 24.5 | ~147 | ||
| After 20% buffer | ~118 hours | |||
Velocity and Story Point Estimation
Velocity is the average number of story points completed per sprint, calculated as a rolling average over the last 3–5 completed sprints. Only completed items count toward velocity — partially done items score zero. This is a critical Scrum principle: half-done work has no delivery value and should not be counted, even if it is 90% complete.
How to calculate rolling velocity
Example: Sprint 6: 34 points, Sprint 7: 41 points, Sprint 8: 38 points, Sprint 9: 36 points, Sprint 10: 40 points. Rolling average over the last three sprints = (38 + 36 + 40) ÷ 3 = 38 points. This is the planning guide for Sprint 11. Using three to five sprints smooths out outliers (a sprint that lost a developer to illness, or an unusually complex epic) without over-weighting distant history.
New teams take 3–5 sprints to establish a reliable velocity baseline. For planning before velocity is established, use 80% of the team's first sprint completion as the initial guide and recalibrate each sprint thereafter.
Story point estimation approaches
Planning Poker: Team members simultaneously reveal estimates using the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21) via cards or a digital tool. Simultaneous reveal prevents anchoring — no one sees anyone else's estimate before committing to their own. Outliers (highest and lowest) explain their reasoning, the team discusses, and re-estimates until convergence. This is the most widely used estimation technique and works well both in-person and remotely.
T-Shirt Sizing: XS/S/M/L/XL, converted to story point ranges (XS=1, S=2, M=5, L=8, XL=13). Good for quick relative estimation of large backlogs during refinement sessions, when precision is less important than getting items into rough size buckets.
Reference Story Technique: The team identifies a "reference story" — a well-understood, previously completed item that represents a 5-point effort — and sizes all new items relative to it. Anchoring estimation to a concrete, known piece of work produces more consistent estimates than working from abstract numbers.
Healthy sprint commitment accuracy targets 85–95%. A team that consistently finishes 100% of its sprint commitment may be under-committing. A team finishing below 80% likely has estimation, dependency, or interruption issues to address. Velocity should be used to guide planning, not to measure team performance — teams under velocity pressure inflate estimates (story point creep) rather than improve throughput.
Turn Your Definition of Done into a Repeatable Checklist
CheckFlow lets you build your Definition of Done as a reusable checklist template — triggered for every story that moves to done. No more "did we actually review the code?" moments at sprint review. Set it up once, run it every sprint.
Start Free TrialThe Sprint Goal
The sprint goal is the most underutilised element of Scrum. Multiple Scrum community surveys consistently find that a significant percentage of teams either do not create sprint goals or create them so vague they provide no decision-making value. "Complete all the stories in the sprint" is not a sprint goal — it is a tautology that adds zero clarity to any scope decision that arises during the sprint.
What makes a good sprint goal
- Specific enough to focus — says what outcome the sprint is working toward, not just what tasks it contains
- Business-meaningful — connects to product value or customer need, not just task completion
- Achievable — can be reasonably met even if an individual story is deprioritised mid-sprint
- Singular — one goal, not a list of goals; a list is a backlog, not a goal
Good vs. weak sprint goal examples
| Weak Sprint Goal | Strong Sprint Goal |
|---|---|
| "Complete all backlog items selected for this sprint" | "Complete payment integration so beta users can make their first purchase" |
| "Sprint 14: Performance improvements" | "Reduce API response times below 200ms for the top 5 customer-facing endpoints" |
| "Bug fixes and feature work" | "Resolve the three critical bugs blocking enterprise onboarding and ship the SSO integration" |
When the sprint goal matters most: when a production issue or urgent request arrives mid-sprint, the sprint goal is the decision-making tool. "Does this change help us achieve the sprint goal? No? Then it's either an emergency — which follows the emergency process — or it waits for the next sprint." Teams without a clear sprint goal make those decisions inconsistently, and every inconsistency erodes stakeholder confidence in the team's planning process.
Definition of Done vs. Acceptance Criteria
This is one of the most misunderstood distinctions in Scrum and a frequent source of quality issues at sprint review. Conflating these two concepts leads to stories being marked "done" that haven't met the team's quality standards, and to quality standards being applied inconsistently across stories.
Definition of Done (DoD)
A shared team agreement on the quality standards every increment must meet before it can be considered complete. The DoD applies to all items in all sprints — it is not negotiable on a per-story basis. It is created by the Scrum Team, owned by the team, and updated through retrospectives as the team's standards evolve.
Example DoD items:
- Code reviewed by at least one other developer
- Unit tests written and passing
- Integration tests passing
- No critical security vulnerabilities introduced
- Feature documented in the appropriate knowledge base article
- Deployed to staging environment
- Product Owner has accepted the implementation
Acceptance Criteria
Story-specific conditions that must be true for a particular user story to be considered complete. Written by the Product Owner (with input from developers), attached to each individual backlog item. Acceptance criteria define what the story does; the Definition of Done defines how well it was done.
The relationship between the two
| Definition of Done | Acceptance Criteria | |
|---|---|---|
| Scope | Applies to all stories | Specific to one story |
| Created by | Scrum Team | Product Owner + Developers |
| Changes | Evolves across sprints (updated in retro) | Written before/during refinement |
| Purpose | Ensures consistent quality | Defines specific story completion |
| Example | "All code must be reviewed" | "User can reset password via email link" |
A story is only done when it meets its own acceptance criteria AND meets the team's Definition of Done. A story that meets all its acceptance criteria but was never code-reviewed has not met the DoD — it is not done, regardless of what the board says. CheckFlow is ideal for operationalising the Definition of Done as a recurring checklist template — every story that reaches "done" triggers the same DoD verification steps, ensuring nothing is skipped under time pressure.
The Complete Sprint Planning Checklist
This checklist covers all three phases of the sprint planning process. Run it as a repeatable process every sprint — the consistency is what produces reliable sprint outcomes over time.
Phase 1: Pre-Sprint Preparation (1–2 days before planning)
Product Owner responsibilities:
- ☐ Product backlog is prioritised with the top 2–3 sprints' worth of items refined
- ☐ All items proposed for this sprint have written acceptance criteria
- ☐ All proposed items have effort estimates (or the team has agreed to estimate in the meeting)
- ☐ Draft sprint goal prepared and ready to propose
- ☐ Any new information (customer feedback, stakeholder changes, market events) communicated to the team ahead of the meeting
- ☐ Any dependencies on external teams or systems identified and flagged
Scrum Master responsibilities:
- ☐ Sprint planning meeting scheduled with all team members confirmed
- ☐ Meeting agenda distributed (sprint goal discussion → capacity check → backlog selection → task breakdown)
- ☐ Previous sprint velocity calculated and visible to the team
- ☐ Sprint capacity calculated for each team member (working days minus leave and ceremony time)
- ☐ Definition of Done reviewed — any updates needed following the previous retrospective?
- ☐ Previous sprint's unfinished items reviewed — will they be carried over or returned to backlog?
Developer/Team responsibilities:
- ☐ Personal availability confirmed (leave, support rotation, external commitments) for the sprint period
- ☐ Any known technical blockers or dependencies flagged to Scrum Master
- ☐ Reference story or calibration story identified for estimation if estimating new story types
Phase 2: The Sprint Planning Meeting
Sprint goal discussion (first 15–20 minutes):
- ☐ Product Owner presents sprint goal proposal and business context
- ☐ Team discusses and refines the sprint goal — is it achievable? Meaningful? Singular?
- ☐ Sprint goal finalised and recorded before any backlog selection begins
Backlog selection (main session):
- ☐ Team reviews available capacity (story points or hours) — establish the planning ceiling
- ☐ Product Owner presents top-priority backlog items in priority order
- ☐ For each item: team confirms understanding (acceptance criteria clear?), confirms estimate is still valid, discusses implementation approach if needed
- ☐ Items selected until sprint capacity is reached — do not exceed capacity
- ☐ Every selected item explicitly connects to (or does not conflict with) the sprint goal
- ☐ Dependencies between selected items identified and sequenced
Task breakdown (if time permits in planning; otherwise in first standup):
- ☐ Selected items broken into implementation tasks (each task ideally ≤1 day)
- ☐ Tasks assigned initial owners (or left unassigned for pull-based assignment)
- ☐ Any items that cannot be estimated or broken down are returned to the backlog for further refinement
Phase 3: Post-Planning Actions (same day as planning)
- ☐ Sprint goal documented in team's tool (Jira, Linear, Azure DevOps, or equivalent)
- ☐ Sprint backlog created with all selected items and sprint goal linked
- ☐ Team capacity document updated and saved
- ☐ Sprint planning notes shared with stakeholders who need to know the sprint focus
- ☐ Any items returned to backlog flagged to Product Owner with reason
- ☐ Sprint planning retro item created if any process issues arose during the meeting (for the end-of-sprint retrospective)
Remote Sprint Planning
Remote sprint planning has become standard — most Scrum teams now operate in distributed or hybrid configurations. The ceremony works well remotely when adapted correctly; it fails when teams simply move the same physical meeting to Zoom without adjusting the format.
Core tools for remote sprint planning
- Virtual whiteboard: Miro, MURAL, or FigJam for collaborative story mapping, voting, and visual planning
- ITSM/project tools: Jira, Linear, Azure DevOps, GitHub Projects for backlog management and sprint creation
- Estimation tools: PlanningPokerOnline.com, Parabol, or built-in estimation features in Jira/Linear
- Communication: Zoom, Teams, or Google Meet — cameras on for planning (non-negotiable for a ceremony this important to team alignment)
Remote-specific adaptations
Preparation: Distribute the proposed backlog items, capacity spreadsheet, and draft sprint goal to all team members 24–48 hours before the meeting. Async reading prevents the meeting from being a first-read session — team members arrive with questions and positions already formed, which makes the discussion faster and more substantive.
Estimation: Planning poker works extremely well in async-friendly tools. Parabol allows async voting with time-boxed reveals, reducing social pressure to anchor on early estimates. The simultaneous reveal principle still applies — use tools that enforce it rather than asking people to type their estimate in chat sequentially.
Timezone challenges: For globally distributed teams, sprint planning is the one ceremony that benefits from overlap time — schedule it during the working window all team members share, even if it means early or late starts. If timezone overlap is severely limited, split planning across two shorter sessions: sprint goal and backlog selection in session 1; task breakdown async or in session 2.
Visual backlog: Use a shared Miro board or the backlog view in Jira/Linear visible to all attendees simultaneously. Avoid screen-sharing from one person's machine — everyone should have an interactive view of the same live backlog, not a passive view of one person's screen.
Decision recording: Remote meetings lose context faster than in-person meetings. The Scrum Master should record sprint goal, capacity, key decisions, and any items returned to backlog in real time in a shared document visible to all attendees. Notes reviewed the day after the meeting are already post-hoc reconstruction; notes written live during the meeting are an accurate record.
Common Sprint Planning Mistakes
Mistake 1: No sprint goal (or a sprint goal that is actually a task list). Symptoms: sprint goal is "Complete all items in the sprint" or "API work and bug fixes." What goes wrong: mid-sprint scope decisions become arbitrary; stakeholders have no coherent narrative for sprint outcomes; the team has no principle for deciding what stays when something unexpected arrives. Fix: write the sprint goal before selecting any backlog items. It should answer "what value will we deliver?" not "what tasks will we complete?"
Mistake 2: Overcommitting (planning to 100% capacity). Symptoms: half the sprint stories carry over every sprint; the team is consistently stressed; sprint reviews apologise for unfinished work. Fix: plan to 80–85% of theoretical capacity. Reserve 15–20% for unplanned work, technical debt, and the inevitable interruptions. Track velocity as a rolling average, not a target, and protect the buffer even when stakeholders push for more.
Mistake 3: No Product Owner in the meeting. Symptoms: team spends 30 minutes debating what a story actually means; acceptance criteria are vague or missing; items are selected that the Product Owner would not have prioritised. Fix: Product Owner attendance at sprint planning is mandatory. Their role is not passive — they are there to clarify, to prioritise, and to help the team select items that achieve the sprint goal. An absent PO produces a sprint backlog that doesn't reflect product priorities.
Mistake 4: Story point inflation under management pressure. Symptoms: velocity climbs each sprint but team throughput (features shipped) stays flat; team members regularly revise estimates upward to "hit their numbers." Fix: use velocity as a planning guide, not a performance metric. Managers should not have access to individual velocity dashboards. Focus team reviews on sprint goal achievement and qualitative retrospective findings, not on whether the number went up.
Mistake 5: Skipping backlog refinement (and expecting planning to compensate). Symptoms: sprint planning meetings run 3–4 hours; items are discussed for the first time during planning; half the stories are returned to the backlog unselected. Fix: dedicate 10% of sprint capacity (roughly 4 hours per two-week sprint) to backlog refinement. No item should enter sprint planning without acceptance criteria and an estimate. The Scrum Master should enforce this as a gate, not a guideline.
Mistake 6: Including too many team members (or the wrong ones). Symptoms: planning becomes a performance for an audience rather than a working session; Product Manager, CTO, QA Director, and three stakeholders all attend and comment on estimates. Fix: sprint planning is a Scrum Team event — Product Owner, Scrum Master, and developers only. Observers should watch silently or not attend. External stakeholders who want to influence priorities should do so through the Product Owner before the meeting, not by attending and applying social pressure during it.
Sprint Planning Metrics
Four KPIs reveal sprint planning health. Track these across 10 sprints to identify patterns — a single sprint's data is noise; 10 sprints' data is a signal.
| Metric | Formula | Healthy Target | Warning Signal |
|---|---|---|---|
| Sprint Commitment Accuracy | (Story points completed ÷ Story points committed) × 100 | 85–95% | Consistently above 95% (under-committing) or below 80% (overcommitting or unplanned interruptions) |
| Sprint Goal Achievement Rate | Sprint goal fully met ÷ Total sprints | ≥80% of sprints | Below 70% signals goals that are too ambitious, or a planning process that doesn't connect selected items to the goal |
| Planning Duration vs. Timebox | Actual meeting duration ÷ Scrum Guide timebox | Completes within 75% of allocated timebox | Consistently running over (>4 hours for a two-week sprint) signals inadequate backlog refinement |
| Carried-Over Item Rate | Items not completed ÷ Total sprint backlog items | ≤10–15% of items per sprint | Items that carry over more than twice consecutively need re-evaluation for feasibility or decomposition |
Sprint Planning Checklist Templates
CheckFlow includes ready-to-use project management templates — free to try, fully customisable, and built to run as live checklists with task assignments, due dates, and completion tracking. The templates below cover sprint planning and the wider project delivery workflows Scrum and project teams run. Click any card to view the full template.
Run Every Sprint from the Same Repeatable Checklist
CheckFlow's recurring sprint planning checklist triggers automatically at the start of each sprint — pre-planning prep, the planning meeting itself, and post-planning actions. Your Scrum Master runs the same proven process every two weeks without starting from scratch.
See How It WorksFAQ
How long should a sprint planning meeting be?
The Scrum Guide timeboxes sprint planning at two hours per week of sprint length — so a two-week sprint gets a four-hour planning meeting maximum, a one-month sprint gets eight hours. In practice, most experienced teams complete two-week sprint planning in 60–90 minutes with good pre-refinement. If your planning meetings consistently run over, it usually means the backlog was not refined before the meeting — stories lack acceptance criteria, estimates are missing, or dependencies have not been discussed.
What is the difference between sprint planning and backlog refinement?
Backlog refinement (also called backlog grooming) is the ongoing process of preparing user stories before they are considered for sprint planning. It happens throughout the sprint — stories are clarified, acceptance criteria are written, and estimates are added. Sprint planning is the ceremony at the start of each sprint where the team selects which refined items to commit to and plans how to execute them. Good refinement makes sprint planning fast and focused; skipping refinement makes sprint planning painful and unreliable.
What is sprint planning commitment vs. sprint goal?
The sprint commitment is the list of specific backlog items the team selects to complete during the sprint. The sprint goal is the single overarching objective that gives the sprint coherence and meaning — it explains why the team is doing this work. A good sprint goal remains valid even if individual items are deprioritised mid-sprint. Teams with clear sprint goals make better scope decisions under pressure than teams who treat the sprint as just a list of tasks.
How do you calculate sprint capacity?
Sprint capacity is calculated by multiplying the number of team members by the available working days in the sprint, then subtracting time for ceremonies (planning, daily standup, review, retrospective), planned leave, and a buffer for unplanned work (typically 20%). The resulting number of available hours — or story points based on historical velocity — is the realistic capacity ceiling. Never plan to 100% capacity; teams consistently operating above 80–85% capacity produce lower quality work and accumulate technical debt.
What is velocity and how is it used in sprint planning?
Velocity is the average number of story points (or work units) a team completes per sprint, calculated as a rolling average over the last three to five sprints. It is the primary input for selecting how much work to commit to in planning. New teams take three to five sprints to establish a reliable velocity baseline. Velocity should be used as a guide, not a target — teams that are pressured to increase velocity each sprint often inflate estimates rather than improve throughput.