Sprint Planning Language

Option B is ideal because it asks concrete, scoped questions rather than rejecting the story or making assumptions.

Why the other options fail:
A — "Skip it" escalates conflict; it's better to ask clarifying questions to make the story ready.
C — Assuming you know what to do is how scope creep happens. Password reset implementations vary widely.
D — Asking about points before understanding requirements puts cart before horse; estimates are meaningless on an unclear story.

Good clarifying questions for user stories cover:
1. Acceptance criteria — "What does Done look like?"
2. Edge cases — "What happens if the user's email doesn't exist?"
3. Out of scope — "Is X in or out?"
4. Dependencies — "Does this need the email service to be set up first?"

Formula: "Can you define what 'done' looks like?" is a universal opener that invites the PO to write acceptance criteria in real time.

Option C models best practice in Planning Poker disagreements:

States a specific estimate: "8 points" — gives the team something concrete to discuss
Explains the reasoning: Names the specific complexity drivers (migration, rollback, DBA coordination)
Stays open to input: "Happy to be talked down if I'm missing something" — invites dialogue without being defensive

Why the others fail:
A — Silent agreement with a wrong estimate isn't consensus; it's hiding a risk
B — "You're all wrong" language is dismissive and shuts down conversation
D — "I pass" without explanation gives the team nothing; it's the same as abstaining from a decision

Planning Poker language patterns:
• "I'm going [X] because…" — explains your card choice
• "My concern is…" — introduces a risk factor
• "Am I the only one thinking about [X]?" — invites others to weigh in
• "Can we split this into two stories?" — proposes a scope change
• "I'd need to investigate [X] before I can estimate" — flags uncertainty honestly

Option B is the correct approach. It follows a Risk → Specific Concern → Proposed Solution → Team Input structure:

Flags the risk professionally: "I want to flag a risk" — signals concern without alarm
Specifies the actual risk: Third-party dependency + recent evidence (last week's downtime) — not vague fear
Proposes two concrete options: Adjust acceptance criteria OR defer — gives the team a choice rather than a veto
Invites dialogue: "What does the team think?" — keeps it collaborative

Why the others fail:
A — "On the record" language creates defensiveness; it's passive-aggressive, not collaborative
C — "Try and move it" normalizes failed sprint commitments; it undermines team predictability
D — "Who approved this?" is accusatory; it attacks process instead of solving the problem

Sprint commitment language:
"I want to flag a risk before we commit…"
"My concern is our capacity — we already have X story points and…"
"Are we comfortable with this dependency on [team/system/third party]?"
"I'd suggest we buffer this with a stretch story rather than a commitment."

Option B demonstrates a vertical slice split — the preferred technique for breaking down large stories without losing value:

Vertical slice: Each resulting story delivers end-to-end functionality (UI → API → DB) — just less of it. Users can actually use Story A while you build Story B.

Horizontal split (avoid): "Story A: build the database layer. Story B: build the UI." Neither story delivers value until both are done.

Common story-splitting patterns:
• Happy path / edge cases — Build the core flow first; handle errors and exceptions next
• CRUD split — Create + Read in Sprint 1; Update + Delete in Sprint 2
• Role split — Feature for registered users first; admin panel second
• Performance split — Functional first; optimised second
• Platform split — Desktop first; mobile responsive second

Why the others fail:
A — "Half of it" is not a coherent story; what does half of "user account creation" even mean?
C — Deferring solves nothing; backlog is where large stories go to be forgotten
D — Re-estimating doesn't change the actual complexity; splitting does