How do you plan a Scrum sprint that actually ships?
Good sprint planning means realistic scope against the team's real capacity, a measurable goal and dependencies cleared before day one — not a meeting where everyone commits to "what feels about right".
Poor sprint planning is the #1 source of missed sprints. The team walks into a two-hour meeting, estimates from the gut, the PO pushes scope over capacity, and by day 8 everyone knows something will not land — but no one formally cuts scope. Good sprint planning looks completely different: it walks in with an already-refined backlog, per-person capacity computed, dependencies cleared and one Sprint Goal that acts as the decision criterion for every later trade-off.
1. Refine before the planning, not inside it
A sprint is not planned on a raw backlog. Two or three days before, run a refinement session where the PO walks the top 10-15 backlog items, the team clarifies acceptance criteria, splits items that are too large and estimates them (story points or t-shirt sizes). The rule: any candidate for the sprint must meet the Definition of Ready — without DoR satisfied, the item stays out of planning, no matter how important it feels.
Refinement is also where you spot external dependencies (other teams, vendors, legal or security decisions) and start moving them. A dependency surfaced inside planning is already a meaningful sprint risk.
2. Real capacity, not historical velocity
Historical velocity is a useful input, but not the only one. Compute the actual capacity for this sprint separately: working days × available hours per person, minus PTO, minus on-call, minus context-switching for production bug-fixes. That is your real capacity.
If the team's historical velocity is 35 SP per sprint, but this one loses two days to PTO and has three urgent inherited PRs, real capacity is closer to 25 SP, not 35. Fill the sprint to real capacity, not the idealised average. Commitments to stakeholders are made against this number, not an average that does not reflect this particular week.
3. One Sprint Goal, written in business language
The Sprint Goal is not "finish 8 tickets". The Sprint Goal is a business outcome: "Cut mobile checkout time by 25%" or "Let new customers import invoices from SmartBill". One goal, in one sentence any team member can repeat from memory.
The goal becomes the decision criterion: on day 5 when you choose between two tasks, you pick the one that serves the goal. On day 8 when you negotiate scope down, you keep what serves the goal and drop the rest. Teams without a clear goal always ship "something", but rarely "the thing that matters".
4. Tasks vs story points: decompose later
Selected stories enter the sprint estimated in story points. Break them into engineering tasks (4-8 hours each) on day one, not inside the planning meeting. Planning is about scope and risk, not detailed technical decomposition.
This boundary keeps planning under two hours for a two-week sprint. Teams who try to decompose everything into one-hour tasks during planning spend 4-5 hours on a meeting that drains the team and produces falsely-precise estimates.
5. Leave buffer for the unexpected
Hold back 15-20% of capacity. Not for "an extra story" — for urgent bug-fixes, technical design conversations, code review, helping a teammate unblock. Teams that fill 100% of capacity miss systematically because any small disturbance becomes a crisis.
That 15-20% is not wasted time — it is when the team actually produces quality. If a sprint truly used none of the buffer (rare), you can pull an extra story as a stretch goal on day 7 or 8.
Plan your sprint in 4myprojects
Visible backlog refinement, capacity calculated from PTO and historical activity, the Sprint Goal pinned to the board, one-click story-to-task split — and AI that warns you before planning if scope exceeds capacity.