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.

Expanding Your Vocabulary: Navigating Disagreement in Planning Poker

Planning poker sessions can be wonderfully collaborative, but they inevitably involve differing opinions about complexity. As a non-native English speaker, understanding the nuances of expressing disagreement constructively is crucial – not just for accurate communication, but also for demonstrating your value to the team and building trust. It’s easy to feel pressure to simply agree with the majority, especially when you’re still developing your professional English vocabulary. Let’s look at some common scenarios and how to approach them.

One frequent situation arises during a code review comment. Imagine Sarah points out a potentially complex algorithm in David’s pull request. She writes: “This section uses a nested loop with multiple conditional checks – could be more efficient.” David, feeling defensive, might immediately respond with “It’s just a small function; I think it’s 3 points.” This is where carefully chosen phrasing becomes vital. Instead of directly arguing (“That’s wrong!”), try something like: “I appreciate your feedback, Sarah. Let me take another look at the loop structure. My initial assessment was 3 points, but hearing your observation about the nested conditions makes sense – it does introduce some complexity. Perhaps I underestimated that.” This acknowledges her point, validates her expertise, and allows you to explain why you initially estimated a different value. Using phrases like “makes sense,” “underestimated,” and “introduces complexity” are good starting points for building your vocabulary around this concept. Another useful phrase is “Let’s discuss this further.”

Slack conversations can also be tricky. Consider a scenario where the team is debating an estimate for a new API integration. Mark suggests 5 points, while Emily proposes 8. Mark might reply with something like, “5 points feels accurate considering the data transformation involved.” Emily responds: “I see your point, but I was thinking about the potential need for error handling and robust logging – that adds significant complexity.” Again, direct confrontation is unproductive. A better approach would be, “Emily, thanks for highlighting the error handling aspect. You’re right; it’s not immediately obvious from the initial requirements. It’s possible I focused too much on the core integration logic and didn’t fully account for those potential issues. Let’s add a point or two to reflect that.” Notice how framing your response as a learning opportunity – “I didn’t fully account” – is a softer, more professional way of expressing disagreement.

Ultimately, remember that planning poker isn’t about assigning absolute numerical values; it’s about collaborative estimation and refining understanding. Focusing on why you assigned a particular estimate allows you to articulate your reasoning effectively and respectfully contribute to the discussion.

# Example using `git` to discuss complexity - illustrating a potential scenario
git diff --stat  # Shows changes made in a commit, useful for estimating effort

# Output (example):
# 10 files changed, 25 insertions(+), 12 deletions(-)
# Modified:   src/main.py
# Modified:   src/utils.py
# ...