Planning Poker English: Agile Estimation Vocabulary and Collocations

Planning Poker is one of the most common estimation activities in agile teams, and if you work in an English-speaking environment, you will encounter its vocabulary in every sprint planning session. From revealing cards to debating complexity, this guide covers the words and phrases that make Planning Poker discussions work — and helps you participate confidently.

Core Vocabulary

Story points A unitless measure of effort, complexity, and uncertainty assigned to a user story. Story points are relative — an 8-point story is roughly twice as complex as a 4-point story, but they do not correspond to hours.

“We estimated the search feature at 8 story points — it’s not that the code is particularly complex, but the uncertainty about the third-party API behaviour adds a lot of unknowns.”

Velocity The average number of story points a team completes per sprint, calculated over several recent sprints. Velocity is used to forecast how much work a team can commit to in future sprints.

“Our velocity over the last four sprints has been between 32 and 38 points — so when planning this sprint, we committed to 35 points as a realistic target.”

Planning Poker A consensus-based estimation technique where team members simultaneously reveal their individual estimates — typically on physical or digital cards using a Fibonacci-like scale — to avoid anchor bias.

“We use Planning Poker for every user story over 1 point — it only takes a few minutes per story and consistently produces better estimates than one person guessing.”

Reveal The moment in Planning Poker when all participants simultaneously show their cards. The simultaneous reveal is essential — it prevents any one person’s estimate from influencing the others.

“On the count of three, everyone reveal your cards at the same time — if you wait to see what others say first, you defeat the purpose of Planning Poker.”

Consensus Agreement on a story point estimate reached after discussion. In Planning Poker, consensus typically means all or most participants agree on a single estimate after one or two rounds.

“We reached consensus on 5 points after the developer explained that the database migration would add complexity — everyone moved their estimates up once they understood that dependency.”

Anchor bias The psychological tendency for the first number heard to disproportionately influence subsequent estimates. Planning Poker prevents anchor bias by having everyone reveal simultaneously.

“We used to estimate by having the lead engineer go first, but that caused anchor bias — everyone else anchored to their number. Simultaneous reveal fixed this completely.”

T-shirt sizing An alternative estimation approach that uses clothing sizes — XS, S, M, L, XL, XXL — instead of numbers. T-shirt sizing is often used for high-level roadmap planning before stories are broken down in detail.

“For the Q3 roadmap session, we used t-shirt sizing instead of story points — it’s faster when stories aren’t well-defined enough for precise estimates.”

Spike A time-boxed research or investigation task used when a story is too unclear to estimate. A spike produces knowledge rather than deliverable software, and enables a more accurate estimate afterward.

“We can’t estimate the Stripe integration story because none of us have used that API — let’s call a spike: someone spends half a day on a prototype, then we re-estimate.”

Relative estimation The practice of sizing stories by comparing them to other stories, rather than trying to predict absolute hours. Relative estimation is the foundation of story points and Planning Poker.

“Don’t try to think about hours — use relative estimation. Compare this story to the login feature we shipped last sprint. Is it more complex, less complex, or about the same?”

Key Collocations

• reveal your cards — “Everyone reveal your cards on three — one, two, three, reveal.”
• reach consensus — “We’ve had two rounds and we’re still split between 3 and 5 — let’s discuss for two minutes and then try to reach consensus.”
• re-estimate after discussion — “After the QA engineer explained the testing complexity, the team agreed to re-estimate after discussion — it went from 3 to 5 points.”
• call a spike — “We don’t know enough about the GraphQL migration to estimate it — I’d like to call a spike before we commit to any story points.”
• adjust velocity — “After two sprints of under-delivery, we adjusted velocity down from 40 to 34 points — better to commit to less and deliver than to over-promise.”
• break down a large story — “The ‘user settings’ story is estimated at 13 points — that’s too big for one sprint, so let’s break down the large story into smaller pieces before planning.”

Using This Vocabulary in Planning Sessions

The most important communication skill in Planning Poker is justifying your estimate. When your card differs significantly from others, you will be asked to explain. A useful structure is: “I estimated [number] because [reasoning]. I was thinking about [specific concern].”

For example: “I estimated 8 because I was thinking about the session management complexity on mobile — I’m not sure we can reuse the web implementation. Did others factor that in?” This shows your reasoning without being combative and invites others to share information you may have missed.

When the group is stuck between two estimates, a facilitator often asks: “What would need to be true for this to be a 3 instead of a 5?” This question focuses discussion on the specific sources of uncertainty rather than abstract disagreement.

The phrase “I’m not sure we’re estimating the same thing” is useful when estimates diverge widely. It suggests that different team members may have different assumptions about the scope, which is usually more productive to explore than debating the complexity of a shared understanding.

Common Mistakes to Avoid

A common mistake for non-native speakers is translating story points directly into hours and then translating back. This defeats the purpose of relative estimation. If you catch yourself thinking “3 points is about 6 hours,” stop and refocus on comparison: “Is this story similar in complexity to the one we called a 3 last sprint?”

Another mistake is treating the Planning Poker estimate as a commitment to a specific hour count. Story points measure complexity, not time. The team’s velocity tells you how many story points typically fit in a sprint, not how many hours each point takes.

Practice Tip

At your next sprint planning session, write down the estimates you were going to give for three stories before hearing anyone else’s view. After the round, compare your written estimates to what the team discussed. Then write one sentence explaining why you would have estimated each story at that number. This exercise builds your ability to articulate estimation reasoning in English — the skill that makes you a more valuable voice in planning discussions.

Navigating Feedback – Beyond “Fix This”

Let’s be honest - a lot of feedback sounds like a demand, particularly early in your career. Phrases like “fix this” or “this needs to be perfect” can feel incredibly daunting and even dismissive of the thought process behind your code. The key isn’t always about immediate fixes; it’s about understanding the why behind the feedback and building a collaborative approach. Recognizing that feedback is often an invitation for clarification, not necessarily a criticism of your abilities, is crucial to navigating those moments effectively.

Consider this scenario: You’ve just submitted a pull request containing several changes – refactoring, bug fixes, and some minor improvements. A week later, you receive Slack message from a senior developer, Sarah, saying “This PR needs major work.” That’s vague and immediately stressful! Instead of defensively trying to prove your worth, consider responding with something like, “Hi Sarah, thanks for the feedback. I’m seeing that the review highlights some areas needing attention. Could we schedule 15 minutes to discuss what specifically you’re referring to? I want to ensure my understanding aligns with yours and understand the reason behind the request.” This shifts the conversation from a vague critique to a collaborative discussion, demonstrating willingness to learn and improve.

Another common situation is receiving a code review comment like, “This function could be more readable – consider adding comments explaining complex logic.” A knee-jerk reaction might be to defensively argue about efficiency or existing documentation practices. Instead, try something like, “Thanks for pointing that out, Sarah. I appreciate the feedback on readability. Could you elaborate on which parts of the function you found most difficult to understand? Perhaps we can discuss adding comments where it’s genuinely unclear – focusing on the core logic rather than a blanket comment style.” This approach acknowledges the validity of the concern while inviting a specific discussion and demonstrating a willingness to adjust your approach. Remember, good feedback is actionable – it provides direction for improvement, not just criticism.

Ultimately, approaching feedback with curiosity and a desire to learn is key. Frame your responses as opportunities for clarification rather than defensive statements. Focus on understanding the underlying concern and collaboratively seeking solutions. Even if you disagree with the initial assessment, respectfully engaging in dialogue demonstrates professionalism and a commitment to continuous improvement – qualities highly valued by employers.