Running Sprint Planning and Execution in Agile Scrum
This skill teaches you how to define a focused sprint goal, select the right backlog items, size commitments against your team's actual capacity, and manage execution so the team delivers working increments reliably every sprint.
Start by defining a single, measurable sprint goal tied to a product outcome. Pull refined backlog items into the sprint until the team's historical velocity is reached, then decompose each item into tasks. During execution, track progress daily, surface blockers in stand-ups, and protect the sprint scope so the team can focus on delivering the committed goal rather than reacting to new requests.
Outcome: Your team consistently plans sprints they can actually finish, delivers working increments every sprint cycle, and builds a predictable cadence that stakeholders can rely on for forecasting.
Prerequisites
- A prioritized and refined product backlog with items estimated in story points or comparable units
- At least 3-5 sprints of historical velocity data (or reasonable initial estimates for new teams)
- Familiarity with agile scrum roles: Product Owner, Scrum Master, and Development Team
- Understanding of user story format and acceptance criteria
Overview
Sprint planning and execution is the operational heartbeat of any Agile team using Scrum. It is the ritual where strategy meets capacity, where a prioritized backlog transforms into a concrete two-week commitment, and where the team negotiates scope against reality. When done well, it creates a reliable rhythm: stakeholders know what to expect, developers know what to focus on, and the product grows in meaningful increments. When done poorly, it produces either overcommitted teams burning out on impossible targets or undercommitted teams coasting through sprints without meaningful progress.
The core artifact produced by sprint planning is the sprint backlog, a curated list of user stories or work items paired with a clear sprint goal that explains why those items matter as a group. The sprint goal is the single most important output of the planning session. Without it, the sprint is just a grab bag of tickets with no coherent purpose. With it, the team has a north star for every daily decision: "Does this help us achieve the sprint goal?" The sprint goal also gives the team flexibility. If a specific story turns out to be harder than expected, the team can negotiate scope with the Product Owner while still delivering on the overarching objective.
Execution, the part that happens after the planning meeting ends, is where most teams struggle. Planning is a controlled event with a clear structure. Execution is two weeks of ambiguity, interruptions, and shifting context. The discipline of agile scrum execution means protecting the sprint scope, surfacing blockers early through daily stand-ups, updating the sprint burndown to maintain visibility, and making mid-sprint trade-offs with the Product Owner when surprises emerge. A team that plans well but executes poorly will still miss commitments. The skill is in doing both.
This skill sits between managing and refining a product backlog, which prepares the raw material for sprint planning, and running sprint retrospectives, which inspects the process after each sprint. Master all three and you have a complete sprint cycle that continuously improves.
How It Works
Sprint planning works by matching team capacity to prioritized work through a structured negotiation between the Product Owner (who controls priority) and the Development Team (who controls feasibility and effort). The Scrum Master facilitates this negotiation and guards the process. Understanding why this negotiation structure exists is essential to running it well.
The fundamental tension in sprint planning is between ambition and reality. The Product Owner always wants more delivered. The team knows their limits better than anyone. Velocity, the average number of story points completed in recent sprints, exists to anchor this conversation in data rather than optimism. A team that completed 34, 38, and 32 points in the last three sprints has a velocity of roughly 35. Planning a 50-point sprint because "we'll try harder" is not planning. It is wishful thinking that erodes trust when it inevitably fails.
The sprint goal acts as a forcing function for coherence. Instead of pulling in the next 35 points of unrelated items from the top of the backlog, the team asks: "What is the one thing we should accomplish this sprint?" The answer might be "Enable users to complete checkout without creating an account" or "Reduce API response time below 200ms for the top 5 endpoints." Once the goal is set, the team selects backlog items that contribute to it, plus a small number of maintenance or carry-over items if capacity allows. This coherence matters because it reduces context switching, creates a shared sense of purpose, and gives the team a basis for mid-sprint trade-offs.
During execution, the sprint burndown chart (or burn-up chart) serves as the team's real-time feedback mechanism. It plots remaining work against time. A healthy burndown slopes steadily downward. A flat burndown on day 5 of a 10-day sprint is a leading indicator of trouble. The daily stand-up is the ritual where the team inspects this trajectory and adjusts. It is not a status report to management. It is a coordination mechanism among peers.
The "Definition of Done" is the quality gate that prevents the sprint from becoming a race to mark stories as complete without actually finishing them. A story is not done when the code is written. It is done when it is code-reviewed, tested, documented if needed, and deployable. Teams that skip this rigor accumulate technical debt that compounds sprint over sprint, eventually slowing velocity to a crawl. The Definition of Done should be written down, agreed upon by the whole team, and applied consistently to every item in the sprint.
Finally, sprint execution in Agile relies on scope protection. Once the sprint starts, no new work enters unless the team and Product Owner explicitly agree to swap something out. This is not rigidity for its own sake. It is the mechanism that makes planning meaningful. If anyone can add work mid-sprint without removing something, the sprint plan is fiction. Teams that tolerate constant scope changes lose the ability to estimate, commit, or predict, which destroys the core value of sprinting in the first place.
Step-by-Step
Step 1: Confirm backlog readiness before the planning meeting
Two to three days before the sprint planning session, the Product Owner and Scrum Master should review the top of the product backlog to ensure enough items are refined and ready for selection. "Ready" means each item has a clear description, acceptance criteria written in testable terms, dependencies identified, and a story point estimate agreed upon by the team. If you find that fewer items are ready than the team's typical velocity requires, schedule a quick backlog refinement session before planning. Do not go into sprint planning with an under-refined backlog, because the planning meeting will devolve into a refinement session and run far over time.
5x your average velocity available, since not all items will be selected.
Tip: Create a simple "Definition of Ready" checklist (description, acceptance criteria, estimate, no unresolved dependencies) and attach it to your backlog board. Items that do not pass the checklist cannot enter sprint planning. This one rule prevents 80% of planning session dysfunction.
Step 2: Set the sprint goal collaboratively
Open the sprint planning meeting by having the Product Owner propose a sprint goal, a single sentence describing the most important outcome this sprint should produce. This is not a list of stories. " The team discusses whether the goal is achievable given their capacity, any planned time off, and known risks. Negotiate until you land on a goal that is ambitious but realistic.
Write the final sprint goal where the whole team can see it. It should stay visible throughout the sprint as the anchor for every prioritization decision.
Tip: If the Product Owner cannot articulate a single sprint goal, it usually means the backlog priorities are not clear enough. Pause and resolve priority before continuing. A sprint without a goal becomes a random collection of tasks with no coherent value delivery.
Step 3: Calculate available capacity for the sprint
Before selecting work, establish how much capacity the team actually has this sprint. Start with the team's average velocity over the last 3-5 sprints. Then adjust downward for known absences: holidays, conferences, on-call rotations, or team members joining or leaving. A team with a 36-point velocity that has one developer out for 3 of 10 days on a 5-person team should plan for roughly 30-32 points, not 36.
Also factor in any carry-over work from the previous sprint. If 8 points of unfinished work are being pulled in, subtract that from the available capacity for new items. Be explicit about these adjustments so the team understands the math behind the plan.
Tip: New teams without velocity history can use a capacity-based approach instead. Multiply the number of available developer-days by a focus factor of 0.6-0.7 (accounting for meetings, code reviews, and context switching), then map that to the estimated hours for candidate stories. After 3-5 sprints, switch to velocity-based planning.
Step 4: Select backlog items that support the sprint goal
Working from the top of the refined backlog, the Product Owner presents items one at a time. For each item, the team confirms they understand the requirements and acceptance criteria, asks clarifying questions, and confirms the existing estimate still feels right. Pull items into the sprint that directly support the sprint goal first. Once the goal-aligned items are selected, check remaining capacity.
If room exists, the Product Owner can propose additional items, these might be small bugs, tech debt, or lower-priority features. Keep a running total of story points as you go and stop when you approach 90-95% of calculated capacity. Never plan to 100% of velocity. Leave a buffer for the unexpected.
Tip: If the team consistently disagrees with existing estimates during selection, your refinement process needs work. Estimates should be finalized during [backlog refinement](/skills/managing-product-backlogs), not relitigated during planning. Sprint planning should spend time on understanding scope, not re-estimating.
Step 5: Decompose selected stories into tasks
For each story selected for the sprint, the development team breaks it down into concrete tasks: specific pieces of implementation, testing, documentation, or deployment work. A story like "Users can reset their password via email" might decompose into tasks such as "Add forgot-password endpoint," "Create email template," "Write integration tests for token expiration," and "Update user-facing help docs." Each task should be small enough to complete in less than a day. This decomposition serves two purposes: it validates that the team actually understands what the story requires (if they cannot decompose it, they do not understand it well enough), and it enables more granular progress tracking during the sprint. Record these tasks in whatever tool the team uses for sprint tracking.
Tip: Time-box task decomposition to 5-10 minutes per story. If a story takes longer to decompose, it is probably too large and should be split into smaller stories. A good heuristic: if a story has more than 7-8 tasks, consider splitting it.
Step 6: Commit to the sprint plan and make it visible
Once all items are selected and decomposed, the Scrum Master summarizes: the sprint goal, the list of selected stories with their total points, the calculated capacity and any adjustments, and the Definition of Done the team will apply. " This is not a vote or a formality. It is a genuine check. If any team member has reservations, surface and address them now, either by removing a story, adjusting scope, or resolving a concern.
Once the team agrees, publish the sprint backlog to the team's board, shared document, or project tool. Ensure the sprint goal is displayed prominently on the board itself, not buried in a description field.
Tip: Record who was present at the planning meeting and the final velocity target. When you run retrospectives later, having a record of what was planned versus what was delivered, and who was in the room, is invaluable for identifying patterns.
Step 7: Execute daily with stand-ups and burndown tracking
During the sprint, the team meets daily for a brief stand-up (15 minutes or less) to synchronize. Each person shares what they completed since yesterday, what they plan to work on today, and what is blocking them. The Scrum Master updates the sprint burndown chart daily, either automatically from the sprint tool or manually. Review the burndown shape: a line trending above the ideal slope means the team is falling behind.
If by mid-sprint the burndown is flat or climbing, the Scrum Master should facilitate a conversation about what is going wrong, whether the team needs to re-scope, or whether a blocker needs escalation. The stand-up is also where the team coordinates on dependencies. If two developers are working on stories that touch the same code, they should pair or sequence their work to avoid conflicts.
Tip: If your stand-up regularly runs over 15 minutes or turns into problem-solving sessions, implement a strict "take it offline" rule. Note the problem, name the people who need to discuss it, and schedule a follow-up immediately after stand-up. Stand-ups are for surfacing, not solving.
Step 8: Protect scope and manage mid-sprint changes
Inevitably, new requests or urgent issues will arise during the sprint. When they do, the Scrum Master's job is to protect the sprint scope. " The Product Owner and team negotiate the trade-off. If the new item is genuinely urgent (production outage, critical security fix), the team swaps it in for a similarly-sized item and adjusts the sprint forecast.
If it is not urgent, it goes to the top of the backlog for the next sprint. Track every scope change, both additions and removals, during the sprint. This data is critical for retrospectives. Teams that experience frequent mid-sprint scope changes have a systemic problem, either with backlog prioritization, stakeholder management, or release processes, that needs to be addressed.
Tip: Create a "sprint interruption log" that records every request to add work mid-sprint, who made it, its urgency, and whether it was accepted. After 3-4 sprints, patterns emerge: maybe 60% of interruptions come from one stakeholder, or most "urgent" items could have waited. This evidence transforms a subjective "we keep getting interrupted" complaint into a specific, actionable problem.
Step 9: Close the sprint with review and measurement
On the last day of the sprint, hold a sprint review where the team demonstrates completed work to stakeholders. Only stories that meet the Definition of Done are presented. Incomplete stories return to the backlog, they do not count toward velocity. After the review, calculate the sprint's actual velocity (total story points of completed, Done stories) and compare it to the plan.
Record this velocity for future planning. Capture the sprint's completion rate (stories completed versus stories planned) and any scope changes. Feed these metrics into the next sprint planning session and into the retrospective where the team will examine what went well and what needs to change. Over time, these metrics build a reliable picture of team throughput that makes planning increasingly accurate.
Tip: Resist the temptation to count partially completed stories in velocity. A story that is 90% done delivers 0% of its value to users if it cannot be shipped. Counting partial work inflates velocity and makes future planning unreliable. If stories are consistently not finishing, they are too large and need to be split smaller.
Examples
Example: B2B SaaS team running a two-week sprint with a feature-focused goal
A 6-person product team at a B2B project management SaaS is planning their next two-week sprint. Their trailing velocity over the last 4 sprints is 32, 36, 30, and 34 story points (average: 33). One developer is on vacation for the first 3 days. The Product Owner's top priority is enabling project templates so users can clone existing project structures.
" The team discusses and agrees this is achievable. They calculate capacity: with one developer out for 3 of 10 days on a 6-person team, they adjust velocity to approximately 28 points (33 minus roughly 15% for the absence). The team pulls in 4 stories directly supporting the template feature: "Create template from existing project" (8 pts), "Browse and preview template library" (5 pts), "Apply template to new project" (8 pts), and "Edit template metadata" (3 pts). That totals 24 points.
With 4 points of remaining capacity, they add a small bug fix (2 pts) and a tech debt task to improve API error handling (2 pts), both labeled as secondary items. Each story is decomposed into tasks. The "Create template" story breaks into 5 tasks: backend data model, duplication logic, UI form, integration tests, and documentation. During execution, on day 4 the team discovers the duplication logic is more complex than expected due to nested dependencies.
In the stand-up, the developer flags this. The team and Product Owner agree to simplify the scope: templates will copy top-level structure but not nested sub-tasks in this sprint. The nested sub-task copying moves to a new story for the next sprint. The sprint finishes with all 4 template stories done (with the agreed simplification), the bug fix done, and the tech debt task done, totaling 28 points.
The sprint review demonstrates the working template feature to stakeholders.
Example: Small startup team with a one-week sprint and a performance goal
A 3-person engineering team at an early-stage B2C mobile app startup runs one-week sprints. Their velocity is volatile (12, 18, 8, 14 points over the last 4 sprints, average: 13). The CEO is frustrated about app load time, and the team has identified 3 performance bottlenecks. All team members are available for the full week.
Given the volatile velocity, the Scrum Master suggests planning conservatively at 10 points. " The team selects three stories: "Lazy-load non-critical modules" (3 pts), "Optimize main database query with indexing" (5 pts), and "Compress and cache static assets" (3 pts), totaling 11 points, slightly above the conservative target but the team feels confident since all three items are well-understood. Task decomposition is quick since the team is small and everyone is familiar with the codebase. 5), freeing up capacity.
The team pulls in one additional small story from the backlog: "Add performance monitoring dashboard" (2 pts), which the Product Owner agrees supports observability for the sprint goal. The sprint finishes with all 4 stories done at 13 points. 8 seconds, beating the goal. The volatile velocity starts to stabilize as the team improves their estimation through consistent measurement.
Example: Large cross-functional team handling a sprint with heavy carry-over
An 8-person team at an enterprise healthcare company runs two-week sprints. Their average velocity is 55 points. However, the previous sprint ended with 18 points of incomplete work: two stories that were blocked by a third-party API integration delay. The Product Owner's priority is completing a compliance reporting module.
Before sprint planning, the Scrum Master facilitates a discussion about the 18 points of carry-over. The team re-examines both stories. One (10 pts) is still blocked because the third-party API sandbox is not available, expected in 5 days. The other (8 pts) was unblocked yesterday and can resume immediately.
The team decides to pull the 8-point story into the sprint but leave the 10-point story in the backlog until the dependency is confirmed resolved, to avoid blocking the sprint again. Effective capacity is 55 minus 8 (carry-over) equals 47 points for new work. " The team selects stories totaling 44 new points plus the 8-point carry-over, reaching 52 total against 55-point velocity, a deliberate 5% buffer given the carry-over risk. On day 5, the third-party API sandbox comes online.
The Product Owner asks to add the 10-point blocked story. The team agrees to swap out a lower-priority 8-point story (a UI polish item) and absorb the 2-point difference within their buffer. This is documented in the interruption log. The sprint finishes with 50 points completed, the compliance module is demo-ready, and the Product Owner presents the audit log to the security team in the sprint review.
Example: Newly formed team running their first real sprint
A 4-person team at a mid-size e-commerce company has just completed agile training and is running their first sprint. They have no velocity history. The backlog has been refined but estimates are rough. The team is nervous about committing to a plan they might not deliver.
Since there is no velocity data, the Scrum Master uses a capacity-based approach. The team has 4 developers for 10 days, giving 40 person-days. 6 focus factor (conservative for a new team learning agile scrum processes), they target 24 person-days of actual development work. " The team selects 3 stories: "Add price range filter component" (roughly 3 person-days), "Add availability filter backend logic" (roughly 4 person-days), and "Integrate filters with existing catalog search" (roughly 5 person-days), totaling approximately 12 person-days.
This feels low against 24 available, so they add two more stories: "Write E2E tests for filter combinations" (3 person-days) and "Update filter design to match new brand guidelines" (3 person-days), reaching 18 person-days. The Scrum Master advises stopping here, well below capacity, because first-sprint estimates are unreliable and it is better to finish everything and build confidence than to overcommit and start the agile journey with a failure. The sprint finishes with all 5 stories complete. The team retrospects and notes they had about 4 person-days of spare capacity.
For the next sprint, they plan slightly higher. By sprint 3, they have enough data to switch to velocity-based planning.
Best Practices
Keep the sprint goal to a single sentence that a stakeholder outside the team can understand. If the goal requires a paragraph to explain, it is either too broad or too vague. A clear sprint goal enables the team to make autonomous decisions during execution without escalating every question to the Product Owner.
Plan to 80-90% of historical velocity, not 100%. Every sprint has interruptions, unexpected complexity, and administrative overhead. Teams that plan to full capacity miss their commitment more often than not, which damages team morale and stakeholder trust. The buffer is not slack. It is realism.
Apply the Definition of Done uniformly to every story, every sprint, with no exceptions. When teams start making "just this once" exceptions, they accumulate unfinished work that compounds. Within a few sprints, the team spends more time finishing old work than delivering new value.
Track velocity as a trend line, not a single number. Any individual sprint can be an outlier due to holidays, team changes, or an unusually complex story. Use the average of the last 3-5 sprints for planning. If velocity is trending downward over several sprints, investigate root causes in retrospectives before they become entrenched.
Ensure every story selected for the sprint has a clear, direct connection to the sprint goal or is explicitly labeled as a secondary item. When half the sprint backlog has no relationship to the stated goal, the goal is decoration rather than direction. This lack of coherence increases context switching and reduces the team's ability to make trade-offs.
Time-box the sprint planning meeting itself. For a two-week sprint, the meeting should not exceed 4 hours. For a one-week sprint, cap it at 2 hours. If the meeting consistently runs over, the root cause is almost always insufficient backlog refinement happening upstream.
Make the sprint backlog and burndown visible to everyone, including stakeholders. Transparency builds trust and reduces status-check interruptions. When a stakeholder can see the burndown chart at any time, they are less likely to ping individual developers asking "how is it going?"
Review carry-over stories critically before automatically pulling them into the next sprint. A story that was not completed may have been blocked for a good reason, may need re-estimation, or may no longer be the highest priority. Carry-overs are not automatic. They go back to the backlog and compete for selection like any other item.
Common Mistakes
Skipping the sprint goal and treating planning as a ticket-pulling exercise
Correction
Without a sprint goal, the planning session becomes a mechanical exercise of filling capacity with the top N items from the backlog regardless of coherence. This produces sprints where the team works on unrelated things, cannot make trade-offs when surprises arise, and delivers increments that do not tell a coherent story to stakeholders. The diagnostic signal is easy to spot: ask any team member mid-sprint what the sprint goal is. If they cannot answer, the goal was either never set or never internalized.
Fix this by starting every planning session with the goal before touching any backlog items.
Consistently overcommitting by planning beyond the team's demonstrated velocity
Correction
This mistake usually stems from pressure to "do more" or from confusing aspirational targets with realistic plans. " They deliver 28 points and carry over 12. The carry-over then distorts the next sprint's planning. The early warning signal is a completion rate below 80% for two or more consecutive sprints.
Fix it by anchoring planning strictly to the trailing 3-5 sprint average and making any deviation a conscious, documented decision with the team's explicit agreement.
Allowing unlimited scope changes during the sprint without formal trade-offs
Correction
When the Product Owner or stakeholders add work mid-sprint without removing something, the sprint plan becomes meaningless. The team either works overtime to absorb the additions or silently drops planned items. Either outcome erodes predictability. The signal is a burndown chart that goes up mid-sprint (more work added than completed) or a growing gap between planned and completed stories.
Fix this by implementing a strict swap-in/swap-out rule: every addition requires an equivalent removal, decided jointly by the Product Owner and team. Track all mid-sprint changes in an interruption log and review the pattern in retrospectives.
Decomposing stories into tasks that are too large to track daily progress
Correction
When tasks are 2-3 days long, the burndown chart stays flat for days and then drops suddenly, making it impossible to detect problems early. The team loses the ability to course-correct mid-sprint because they do not know they are behind until the task is overdue. A healthy task board should show movement every day. If a developer's task has been "in progress" for more than a day without visible progress, the task is too large.
Fix this by enforcing a maximum task size of one day or less. If a task cannot be completed in a day, split it further.
Using the daily stand-up as a status report to the Scrum Master or manager instead of a peer coordination meeting
Correction
When team members address the Scrum Master rather than each other, the stand-up becomes a reporting ritual rather than a planning tool. The signal is that people speak in the direction of the Scrum Master, nobody asks follow-up questions, and the meeting feels like a round-robin checklist. Fix this by having the Scrum Master step back physically and visually. Encourage team members to address each other directly.
" The stand-up should help the team self-organize, not feed information upward.
Counting unfinished stories as partial velocity at the end of the sprint
Correction
Teams sometimes count a 5-point story as "3 points done" if most of the work is complete but it did not meet the Definition of Done. This inflates velocity, which causes overcommitment in future sprints, which causes more incomplete stories, creating a vicious cycle. Velocity measures delivered value, not effort expended. A story that is 90% coded but not tested and not shippable has delivered zero value.
Fix this by enforcing a binary rule: done or not done, counted or not counted. If stories are frequently almost-but-not-quite done, the root cause is usually that they are too large and need to be split into smaller, independently deliverable pieces.
Other Skills in This Method
Comparing Agile and Waterfall for Project Selection
How to assess project characteristics, risk profiles, and organizational constraints to decide when agile outperforms waterfall and vice versa.
Choosing Between Scrum, Kanban, and Hybrid Approaches
How to evaluate your team's context and workflow to select the right agile framework — Scrum, Kanban, Scrumban, or a custom hybrid.
Scaling Agile Across Multiple Teams and Departments
How to apply scaling frameworks like SAFe, LeSS, or Nexus to coordinate agile practices across multiple teams while preserving agility.
Managing and Refining a Product Backlog
How to create, prioritize, groom, and maintain a product backlog with well-written user stories, acceptance criteria, and effort estimates.
Coaching Teams Through Agile Adoption and Transformation
How to guide resistant or inexperienced teams through the agile transition by building trust, teaching agile values, and establishing sustainable practices.
Running Sprint Retrospectives for Continuous Improvement
How to facilitate retrospectives that generate honest feedback and produce actionable improvements the team actually implements.
Facilitating Effective Daily Stand-Up Meetings
How to run focused, time-boxed daily stand-up meetings that surface blockers, align the team, and maintain momentum without wasting time.
Related Skills from Other Methods
Frequently Asked Questions
How long should a sprint planning meeting take?
The Scrum Guide recommends a maximum of 8 hours for a one-month sprint, which scales proportionally: 4 hours for a two-week sprint and 2 hours for a one-week sprint. If your planning consistently exceeds these time-boxes, the most common root cause is insufficient backlog refinement happening before the meeting. Stories arriving at planning without clear acceptance criteria or estimates force the team to do refinement work during planning, which doubles the meeting duration. Fix the upstream process and planning meetings will shrink naturally.
Should I use story points or hours to estimate sprint work?
Story points are generally better for sprint-level planning because they measure relative complexity rather than absolute time, which accounts for the reality that different developers work at different speeds and unforeseen complexity often inflates hour estimates. Hours work better at the task level, where individual developers can estimate their own work more accurately. Many teams use a hybrid approach: story points for backlog estimation and velocity tracking, then hours (or simply small/medium/large tasks) during the decomposition step of planning. The key is consistency. Pick one system for velocity tracking and stick with it for at least 5-6 sprints before evaluating whether it is working.
How do I handle a sprint where we finish early?
Finishing early is a signal, not a problem. First, verify the team genuinely finished. Are all stories truly Done per the Definition of Done, including testing and documentation? If yes, the team can pull the next highest-priority item from the product backlog into the current sprint, after a quick conversation with the Product Owner to confirm priority. Do not treat this as proof the team should plan more aggressively. Consistent early finishes over 3-4 sprints are the signal to gradually increase planned velocity by 5-10%, not to suddenly jump 30%. One-time early finishes are often flukes caused by stories being simpler than estimated.
What happens when a story is not finished at the end of the sprint?
Unfinished stories return to the product backlog. They do not count toward the sprint's velocity, and they are not automatically included in the next sprint. The Product Owner re-prioritizes them alongside all other backlog items. Sometimes the unfinished story is still the highest priority and gets selected again. Sometimes priorities have shifted and it drops. If stories are frequently unfinished, diagnose the root cause: stories may be too large (split them smaller), estimates may be off (improve refinement), or mid-sprint interruptions may be consuming capacity (track and address in retrospectives).
Should I run sprint planning before or after the retrospective from the previous sprint?
Run the retrospective first. The retrospective inspects what happened in the previous sprint and produces action items for improvement. Those action items may directly affect how you plan the next sprint. For example, if the retrospective reveals that the team over-committed because they ignored a team member's vacation, the next sprint planning should explicitly account for absences. Many teams run the sprint review, retrospective, and next sprint planning in sequence on the same day, which creates a clean boundary between sprints. If you plan first and retro later, you lose the opportunity to immediately apply learnings.
How do I convince stakeholders to stop adding work mid-sprint?
Data is more persuasive than process arguments. Start tracking mid-sprint additions and their impact: how many points were added, what was dropped to accommodate them, and what the completion rate was for sprints with many additions versus sprints with few. After 4-5 sprints, present the pattern. Something like "Sprints with fewer than 3 points of additions complete 92% of planned work. " Offer stakeholders a constructive alternative: a prioritized request queue that gets reviewed at the next sprint planning, with a fast-track process reserved for genuine emergencies.
How do I adapt sprint planning for a remote or distributed team?
The mechanics are the same, but the facilitation needs more structure. Use a shared digital board (Jira, Linear, or Miro) that everyone can see and edit simultaneously. Have the Product Owner share their screen while presenting each story so the team reads from the same view. Use explicit round-robin facilitation for estimation and commitment checks, because people are less likely to speak up unprompted on video calls. Build in 5-minute breaks every 45 minutes since remote meetings cause fatigue faster. Record the sprint goal and commitment in a shared document, not just verbally, since chat-based records get buried. Consider asynchronous pre-work: share the candidate stories 24 hours before planning so team members arrive with questions prepared rather than reading stories for the first time in the meeting.