Good sprint planning answers the three questions in the 2020 Scrum Guide: why this sprint is valuable (the Sprint Goal), what can be done this sprint (selected backlog items, sized against real capacity), and how the work will get done (the developers' plan). It is timeboxed to a maximum of 8 hours for a one-month sprint and is usually shorter for shorter sprints; most two-week teams that arrive with a refined backlog finish in about 2 hours.
Below: what the Scrum Guide actually requires, a reusable 2-hour agenda, a worked capacity calculation with real numbers, and the mistakes that make planning drag or produce sprints that fail.
What the 2020 Scrum Guide says
Many sprint planning articles describe practices that aren't in Scrum (commitment to a fixed scope, hour-by-hour task estimates). The guide itself is short. The key points:
| Element | What the guide says |
|---|---|
| Who | The whole Scrum Team. Others can be invited to give advice |
| Topic 1: Why | The Product Owner proposes how the product could increase value this sprint; the whole team collaborates on a Sprint Goal, finalized before the event ends |
| Topic 2: What | Developers select items from the Product Backlog, in discussion with the PO. The more they know about past performance, upcoming capacity and their Definition of Done, the more confident their forecast |
| Topic 3: How | Developers plan the work needed to create an increment that meets the Definition of Done, often by decomposing items into work of one day or less. How they do this is up to them |
| Timebox | Maximum 8 hours for a one-month sprint; usually shorter for shorter sprints |
| Output | The Sprint Backlog: Sprint Goal + selected items + the plan |
Two things follow from this. The Sprint Goal is the commitment; the selected items are a forecast and can be renegotiated with the PO during the sprint as long as the goal holds. And the "how" belongs to the developers. Managers and the PO don't assign tasks.
Before planning: what needs to be true
Sprint planning is fast when the hard thinking happened earlier.
- Refined backlog: roughly a sprint's worth of items at the top meet your Definition of Ready and are already estimated. If you're estimating from scratch in planning, the meeting will double in length.
- Known velocity: an average of the last 3-6 sprints of completed points. The sprint velocity calculator and how to calculate team velocity cover this.
- Known availability: everyone has entered time off, on-call, training and public holidays.
- A draft goal: the PO arrives with a proposed objective, not just a list.
A 2-hour sprint planning agenda (two-week sprint)
| Time | Topic | Who leads | Output |
|---|---|---|---|
| 0:00-0:10 | Context | Scrum Master | Last sprint's outcome in one sentence, carry-over items, any release or dependency news |
| 0:10-0:25 | Why: propose and discuss the goal | Product Owner | Draft Sprint Goal on screen |
| 0:25-0:40 | Capacity | Developers | Available capacity in points (see the worked example) |
| 0:40-1:10 | What: select items | Developers with PO | Ordered list of items that serve the goal, within capacity. Quick planning poker for any item not yet estimated |
| 1:10-1:15 | Break | ||
| 1:15-1:45 | How: plan the first days | Developers | Each item broken into tasks for at least the first few days; owners for day-one work; risks and dependencies listed |
| 1:45-1:55 | Finalize goal and check | Whole team | Sprint Goal reworded if needed; quick confidence check |
| 1:55-2:00 | Close | Scrum Master | Sprint Backlog visible; questions logged |
For a one-week sprint, halve each block. For a one-month sprint, you may need a longer "how" section, but if you are anywhere near 8 hours, the backlog wasn't refined.
Facilitation lines that keep it moving
- Opening the goal: "If we only finished one thing this sprint, what would make it worth it?"
- When selection exceeds capacity: "We're 9 points over. Which of these doesn't serve the goal?"
- When a story turns out to be unclear: "Can we start it with what we know, or does it go back to refinement?"
- Closing: "On a scale of 1 to 5, how confident are you we'll meet this goal?" Any 1s or 2s get a minute of discussion before you end.
That last question is a fist-of-five. Alignlee's Confidence Pulse mode runs it as a quick 1-5 vote and shows the team average, which is handy for remote teams where hands-in-the-air doesn't work.
Writing a sprint goal that's useful
A sprint goal should be an outcome you can check at the sprint review, narrow enough to guide trade-offs during the sprint.
| Weak goal | Why | Better goal |
|---|---|---|
| Complete stories ABC-101 to ABC-112 | That's a list, not a goal | Returning customers can reorder a previous purchase in two clicks |
| Improve performance | Not checkable | Product search responds in under 1 second for our 10 most common queries |
| Work on the payments epic | No outcome | Customers in Canada can pay in CAD at checkout |
| Fix bugs and do features | Two goals, neither guiding | Cut checkout support tickets by fixing the three top-reported checkout bugs |
The test: halfway through the sprint, a developer must choose between two tasks. Does the goal tell them which one matters more? If not, sharpen it.
Capacity planning: a worked example
Velocity tells you what the team usually finishes. Capacity adjusts that for this specific sprint.
The team: 5 developers, two-week sprint (10 working days). Average velocity over the last 5 sprints: 40 points.
Step 1: available person-days this sprint
| Developer | Working days | Time off | On-call / support | Other (training, interviews) | Available days |
|---|---|---|---|---|---|
| Ana | 10 | 0 | 2 | 0 | 8 |
| Ben | 10 | 3 (vacation) | 0 | 0 | 7 |
| Chen | 10 | 0 | 0 | 1 | 9 |
| Dana | 10 | 1 (holiday) | 0 | 0 | 9 |
| Eli | 10 | 0 | 0 | 0.5 | 9.5 |
| Total | 50 | 42.5 |
Step 2: compare to a normal sprint. In the sprints that produced the 40-point average, the team typically had about 47 available days (the usual mix of on-call and occasional time off).
Step 3: scale velocity
Capacity = 40 × (42.5 ÷ 47) ≈ 36 points
Step 4: leave a buffer. Ben's vacation removes the team's only person familiar with the reporting module, and there's a dependency on another team's API. The team plans to 32-33 points and keeps one 3-point story as a stretch item that serves the goal if things go well.
Step 5: carry-over. A 5-point story is half-finished from last sprint. Re-estimate the remaining work (say 3 points) rather than counting all 5 again, and include it in the 33.
Notes on the method:
- Use the same definition of "available" in your history and your plan, or the scaling is meaningless.
- Don't convert points to hours per person. Scaling the team's total keeps points relative; see story points vs hours.
- New team members usually need a few sprints before they add full capacity. Count them at partial capacity at first.
Common sprint planning mistakes and fixes
| Mistake | Symptom | Fix |
|---|---|---|
| Estimating in planning | Planning takes 4+ hours for a two-week sprint | Estimate in refinement; only quick-poker the stragglers. See how to shorten refinement |
| Planning to 100% of velocity | Sprints regularly finish with carry-over | Plan to capacity minus a buffer; keep a stretch item |
| Goal written last, as a summary | Goal is a list of story titles | Start with the goal; select items that serve it |
| Ignoring unplanned work | Support and bugs eat the sprint | Track how much unplanned work typically lands and reserve that much capacity, based on your own history |
| Manager or PO assigns tasks | Developers disengage; "how" isn't owned | Developers plan the how and pick their own work |
| Every task planned for 10 days | Plan is out of date by day 3 | Plan the first few days in detail; the rest emerges in Daily Scrums |
| Pressure to take more | Points inflate, velocity rises, delivery doesn't | Show the capacity table; discuss scope, not estimates |
| Forgetting the Definition of Done | Stories "done" but untested or undeployed | Size items to include everything in the Definition of Done |
Remote and distributed sprint planning
- Share the draft goal and candidate items a day ahead so the meeting is for deciding, not reading.
- Use a shared board everyone can edit, not one person's screen.
- Ask for confidence with simultaneous votes rather than "any concerns?" Silence on a video call isn't agreement.
- Across wide time zones, consider doing capacity input and question-gathering async and keeping the live part to the goal and selection.
FAQ
How do you run a sprint planning meeting?
Start with the Product Owner proposing an objective and the team agreeing a Sprint Goal (why), then calculate capacity and select refined backlog items that serve the goal (what), then let developers break the first items into tasks and plan the first days (how). End by confirming the goal and checking the team's confidence. Most two-week sprints need about 2 hours if the backlog was refined beforehand.
What is a good sprint planning agenda?
A simple version: context and carry-over (10 min), Sprint Goal (15 min), capacity (15 min), item selection (30 min), task planning (30 min), finalize and confidence check (10 min). Halve it for one-week sprints. Planning that regularly runs much longer usually means stories are being refined and estimated in the meeting.
How long should sprint planning be?
The 2020 Scrum Guide sets a maximum of 8 hours for a one-month sprint and says it is usually shorter for shorter sprints. Many teams scale it proportionally, so up to 4 hours for two weeks, but a team with a refined, estimated backlog typically finishes a two-week planning in 1-2 hours.
What are the three topics of sprint planning?
Why is this sprint valuable (the team agrees a Sprint Goal), what can be done this sprint (developers select Product Backlog items based on capacity and past performance), and how will the chosen work get done (developers plan the work, often into pieces of one day or less). Together these produce the Sprint Backlog.
How do you do capacity planning for a sprint?
Add up each person's available days after time off, on-call and other commitments, compare that to a typical sprint, and scale your average velocity by the ratio. Then subtract a buffer for known risks and re-estimate any carry-over by remaining work. The worked example above takes a 40-point average down to a 33-point plan for a sprint with a vacation and a dependency.