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.