How to Estimate Story Points in English During Planning Poker

Planning poker asks you to do something oddly specific in a second language: justify a number out loud, in real time, and sometimes defend a very different guess than the rest of the room. The estimate itself is subjective, but the language around it follows patterns you can prepare for.

Key Vocabulary

Justifying an estimate with a reference point — anchoring your number to a similar, previously-completed piece of work, rather than presenting it as a guess out of nowhere. “I justified my estimate with a reference point: I gave this a 5 because it’s similar in scope to the notifications feature we shipped last sprint, which also took about that long.”

Flagging hidden complexity — pointing out a part of the work that isn’t obvious from the ticket description but that you know will add effort, so the team’s estimate accounts for it. “I flagged hidden complexity: the ticket looks small, but it touches the legacy billing code, which historically takes longer than expected because of the lack of tests.”

Reconciling a wide spread — when estimates differ a lot between team members, explaining the reasoning behind the outlier so the group can understand the gap rather than just averaging it away. “We had a wide spread — some estimated 2, I estimated 8 — so we paused to reconcile it: it turned out I was accounting for a database migration that others didn’t realize was needed.”

Re-estimating after new information — updating a number mid-discussion once new context comes up, and saying so explicitly rather than silently changing your card. “After hearing about the API rate limits, I’m re-estimating from a 3 to a 5 — that constraint changes the approach significantly.”

Common Phrases

• “I gave this a [number] because it’s comparable to [past work].”
• “I think this is bigger than it looks, because [hidden complexity].”
• “Can we talk through why the estimates are so spread out?”
• “Given what [name] just said, I’d actually revise my estimate to [new number].”
• “I don’t have enough information to estimate this confidently — can we split it into a spike first?”

Example Sentences

Justifying a low estimate: “I put this at a 2 — it’s essentially the same pattern as the email verification flow we built two sprints ago, just with a different trigger condition.”

Flagging complexity others might miss: “On the surface this looks like a 3, but the underlying service doesn’t have any test coverage right now, so I’d bump it to a 5 to account for writing tests as we go.”

Reconciling a spread of estimates: “Let’s talk about the gap — I see a 1 and an 8 on the table. [Name], what made you estimate high? … Ah, that makes sense, I didn’t realize this also required a schema change.”

Proposing a spike instead of a number: “Honestly, I don’t feel confident putting a number on this yet — there’s too much we don’t know about the third-party API. Can we timebox a one-day spike first and estimate after?”

Professional Tips

• Always justify your estimate with a reference point — comparing to known past work makes your number credible and easy to discuss.
• Proactively flag hidden complexity the ticket doesn’t mention — this is one of the most valuable things you can contribute in planning poker.
• When estimates are far apart, don’t just average them — reconcile the spread by asking what the high or low estimator saw that others didn’t.
• It’s completely acceptable to re-estimate out loud after hearing new context; changing your mind visibly is a sign of good listening, not inconsistency.
• If a ticket is too vague to estimate honestly, say so and propose a spike rather than guessing a number you don’t believe in.

Practice Exercise

1. Write a sentence justifying a story-point estimate by comparing it to a past piece of work.
2. Draft a sentence flagging hidden complexity in a ticket that looks simple on the surface.
3. Practice the phrase “given what [name] just said, I’d revise my estimate to…” out loud.