The Sprint Goal is the commitment. The selected items are a forecast.
That distinction decides what happens when a Sprint goes badly. A team that has confused the two treats every unfinished item as a failure. A team that hasn't can drop an item, hold the goal, and still succeed.
Ask why before anybody looks at the board
Open with the Product Owner, deliberately, before the backlog is on screen:
“What's the most valuable objective for this Sprint? What would define success from a product perspective?”
Beauty Spot's answer came back in terms of users being able to do something — enter the app, create an account, feel they had a personalised space. Not “we should do US1.1 through US1.3.”
That is what asking the question first buys you. Start from the backlog and you get a list of tickets with no reason, and a Sprint Goal written afterwards as a summary of what was already chosen — which is precisely backwards.
The step most teams skip entirely
Before anybody can sensibly say whether a forecast is achievable, somebody has to know how many hours actually exist.
CAPACITY FOR THIS SPRINT Developers 2 Working days in the Sprint 10 Hours per day 8 ─────── Gross 160 h Less Scrum events Sprint Planning 4 h Daily Scrums (10 × 15 min) 2.5 h Sprint Review 2 h Retrospective 1.5 h (per developer, doubled) −14 h ─────── Available 146 h Less focus factor × 0.65 ─────── NET DEVELOPMENT CAPACITY ≈ 95 h FORECAST US1.1 New User Account Registration 26–40 h US1.2 Secure User Login 18–26 h US1.3 Profile Personalisation 14–22 h ─────────── 58–88 h Capacity 95 h against 58–88 h. It fits — but at the top of that range there is almost nothing spare, and this team had never worked together.
Without that table, “does this feel achievable?” is a question about mood. Somebody optimistic says yes, everyone nods, and the Sprint fails for reasons that were sitting in plain sight on day one.
The focus factor is the honest part.
Nobody writes code for eight hours a day. Interruptions, environment problems, code review, a colleague appearing at your desk with a question. Sixty to seventy per cent is normal for a settled team, and lower for a new one.
Anyone planning at a hundred per cent isn't being optimistic. They are planning to fail.
Splitting beats cutting
The forecast was tight, and something had to give. Watch what the Product Owner did with it.
“The nickname is a simple addition and it adds the welcome factor. The picture brings dependencies — image storage. What if we take the nickname now and defer the picture to Sprint 2?”
He didn't cut US1.3. He split it — took the part delivering most of the value for a fraction of the cost, and deferred the expensive part. The user still gets a personalised identity. The team avoids an infrastructure decision it would have made badly under time pressure.
| Before | US1.3 — profile personalisation: nickname and picture | 14–22 h |
| After | US1.3 — display nickname only | 6–10 h |
| Deferred | Profile picture upload — image storage, resizing, moderation, CDN | Sprint 2 |
What is the smallest version of this that still delivers the benefit in the "so that" clause?
A deferral made in Planning is a decision. The same deferral made in week two is a failure.
Same outcome. Entirely different cost.
What this Sprint Planning also let through
Worth recording, because the point of publishing a real artifact is that it contains real mistakes.
US1.1 failed the team's own Definition of Ready on the open-dependency line before this session started. Nobody asked, during Planning, whether anything previously flagged was still unresolved.
It went into the Sprint. It surfaced on day eight and was never cleared, and what it cost is in chapter 1, free to read.
The fix costs one sentence. Ask, out loud, of every selected item: is anything on this unresolved? That question became the team's single improvement action after Sprint 1, and it caught the identical problem in Sprint 2 Planning.
What to produce by the end
- A Sprint Goal — one sentence, stated in terms of what users will be able to do
- A forecast — the selected items, and the arithmetic showing they fit
- A task breakdown — done by the Developers, with ranges rather than single numbers
- Anything deferred — written down, with the reason, so the decision survives being questioned later
Where this sits
Sprint Planning consumes what the chain produced. Items arrive here having passed through Epic slicing, acceptance criteria and the Definition of Ready. If Planning routinely turns into a design session, the problem is upstream of this room.