Sprint Planning is the meeting a Scrum team holds at the start of every sprint to answer three questions: what will this sprint deliver (Sprint Goal), which items from the backlog go in (Sprint Backlog), and how will each be built (task breakdown and approach). When the meeting ends, the team starts work with a clear sprint goal and an executable task list.
The 30-Second Version
- Frequency: once per sprint, fixed on day one of the iteration;
- Duration: two-week sprint โ no more than 2 hours; one-week sprint โ 1 hour;
- Attendees: the whole Scrum team โ developers, Product Owner, Scrum Master;
- Output: 1 Sprint Goal + 1 Sprint Backlog (broken down into executable tasks);
- Pass/fail test: after the meeting, every member can say from memory "these are the things we're building this sprint."
Where Sprint Planning Sits in the Cycle
Sprint Planning (day 1)
โ
Daily Standup ร 9 days
โ
Sprint Review (demo) + Sprint Retrospective
โ
Next Sprint Planning
Planning consumes the outputs of the previous step: the Product Backlog and the improvement actions from the last Retrospective. How the two meetings relate: see the Sprint Retrospective guide.
Pre-Meeting Preparation (half of the meeting's efficiency)
| Preparation item |
Owner |
Standard |
| Product Backlog ordered |
Product Owner |
Top candidate items are clear enough โ no need to explain context live |
| Candidate items refined |
Product Owner + dev team |
The top 1.5โ2ร capacity worth of items are broken down / estimated |
| Team capacity calculated |
Scrum Master |
Effective person-days after leave, meetings and on-call deductions |
| Carry-over from last sprint decided |
Dev team |
Unfinished items: back to backlog or into this sprint โ decided before the meeting |
| Definition of Done ready |
Team |
Everyone agrees on what "done" means |
Without a prepared backlog, planning becomes a requirements-clarification meeting โ the most common cause of overrun.
Agenda Template (2-hour example for a two-week sprint)
| Time |
Segment |
What happens |
| 0:00โ0:10 |
Set the goal |
PO proposes the business outcome; the team converges on a one-sentence Sprint Goal (e.g. "admins can export reports") |
| 0:10โ0:50 |
Pick items |
Walk the backlog in order: does this go in? Subtract against capacity until it's full |
| 0:50โ1:40 |
Break down tasks |
For each selected item, break out 0.5โ1 day tasks and note the technical approach; settle disputed technical risks on the spot |
| 1:40โ1:55 |
Risks and dependencies |
External dependencies (third-party APIs, design assets, other teams), on-call arrangements, priority of known bugs |
| 1:55โ2:00 |
Confirm and commit |
Restate the Sprint Goal and item list; everyone confirms; name the day-one starting tasks |
How to Compute the Three Key Inputs
1. Capacity
Effective person-days = members ร working days โ leave โ meeting overhead โ on-call adjustment
Example: a 5-person team, 10 working days, 3 days of leave total, standing meetings costing ~2 person-days โ 45 โ 3 โ 2 = 40 effective person-days.
2. Velocity
Take the average or median story points completed over the last 3โ5 sprints (the median resists volatility better). New team without history? Estimate from capacity: 1 person-day โ 1 unit of effective work, then switch to story points after two sprints. Misconceptions about velocity: see the FAQ.
3. Estimation
- Planning Poker is the usual tool: everyone reveals a card at once; items with big spreads get discussed and re-estimated;
- Granularity rule: items above 8 points get split before entering the sprint;
- Points estimate relative effort, not hours โ never use them for individual performance reviews.
Common Mistakes and Fixes
| Mistake |
Consequence |
Fix |
| Planning to 100% of capacity |
Zero buffer; one surprise bug breaks the sprint |
Plan to 80% of capacity; leave room for unexpected defects and collaboration overhead |
| PO explains requirements verbally in the meeting |
The meeting turns into a requirements-clarification session |
Refine items before the meeting; in the meeting, confirm โ don't teach |
| Selecting items without breaking them down |
"How" gets figured out mid-sprint, when it's too late |
Break down to 0.5โ1 day tasks and sanity-check the technical approach |
| The goal is an item list, not a business outcome |
The team is accountable for "finished", not for "useful" |
The Sprint Goal must be one business-oriented sentence |
| Last sprint's bugs never prioritized |
The new sprint's plan gets wrecked by surprise defects |
Decide the fate of carried-over bugs in the meeting (see next section) |
Where Do In-Sprint Bugs Go?
A frequently skipped part of planning: which defects this sprint will handle, and whose triage mechanism is running. Make these explicit in the meeting:
The carry-over bug list and their fates (fix / downgrade / close);
The flow for new bugs during the sprint: triage โ classify (P0 handled same day, P1 into this sprint, P2 to the backlog). How to triage: the Bug Triage guide;
One entrance for bug reports: reports from testers or users must carry reproduction steps, screenshots and Console errors โ not scatter across group chats.
Point 3 is the hidden lever on sprint speed: a report with full context lets a developer start fixing immediately, no back-and-forth. BugCapturer's approach here: every submission automatically attaches an annotated screenshot/recording, the URL, browser environment and Console/Network errors (see the diagnostics feature), and reports are pushed automatically into a Slack / Microsoft Teams channel โ so when the planning meeting assigns defects, people grade them straight from the reports in the channel, without spending meeting time on "wait, what exactly is this problem?"
FAQ
Q: What is a Sprint Planning meeting?
A: The planning meeting at the start of each sprint in Scrum; it decides the sprint's scope (what) and approach (how), and produces the Sprint Goal and Sprint Backlog.
Q: What is Sprint Planning from a business analyst's (BA) perspective?
A: The BA focuses on testability and acceptance criteria: making sure selected items carry acceptance conditions and clear edge cases, and translating stakeholder needs into backlog items.
Q: How long should planning take?
A: Rule of thumb: at most 1 hour per sprint-week โ a one-week sprint gets 1 hour, a two-week sprint gets 2. Overruns usually mean insufficient pre-meeting refinement.
Q: How does a remote team run planning?
A: Video call plus a shared board (Jira/Linear/Trello) as usual; use a collaborative whiteboard to write tasks in parallel during breakdown โ about twice as fast as reading items out serially.
Q: Mid-sprint we realize the plan was too small. Now what?
A: Don't stuff items in mid-sprint. Note them down and give them priority in the next planning meeting; urgent ones go through the P0 triage lane.