6 exercises — explain and defend story points, planning poker disagreements, T-shirt sizing, and velocity in clear professional English.
0 / 6 completed
1 / 6
A product manager asks: "Why did this ticket get 8 story points instead of a time estimate like '3 days'?" What is the correct explanation?
Story points measure relative complexity/effort, deliberately decoupled from calendar time. This lets teams compare stories to each other ("this is about as complex as that other 5-pointer") without pretending to predict exact hours, which vary by person, interruptions, and unknowns.
Key phrase: "story points measure relative effort/complexity, not calendar time." Velocity (points completed per sprint) is what converts points into a rough time forecast at the team level — not at the individual-story level.
2 / 6
During planning poker, you and a colleague reveal very different estimates — you say 3, they say 13 — for the same story. What is the correct next step, and how do you phrase it?
The whole point of planning poker's simultaneous reveal is to surface disagreement and discuss the underlying assumptions — a large spread (3 vs. 13) usually means one person sees hidden complexity the other doesn't. Averaging or picking a "winner" defeats the purpose.
Formula: "We have a big spread — [X] versus [Y]. Can you walk me through what you're seeing? Let's discuss before we re-vote." After discussion, the team re-votes; the conversation, not the arithmetic, is what produces a better estimate.
3 / 6
You need to explain T-shirt sizing (S/M/L/XL) to a new team member who is used to numeric story points. Which explanation is correct?
T-shirt sizing trades precision for speed — it's used when you need a rough comparison (is this epic bigger than that one?) without the overhead of detailed point estimation. It's explicitly coarser than numeric points, which is a feature, not a limitation, in early-stage planning.
Useful phrase: "T-shirt sizing avoids false precision — we don't know enough yet to justify a specific number, so we use a rough bucket instead." Teams often convert T-shirt sizes to point ranges once a story moves closer to being worked on (e.g. "M" ≈ 3–5 points).
4 / 6
A stakeholder says: "This story is only 3 points, so it should only take half a day since our last 3-pointer took half a day." What is the correct pushback?
A common misunderstanding is treating story points as a disguised time unit with a fixed conversion rate. The correct correction restates that points are relative, and any time correlation only emerges statistically at the team/sprint level via velocity — not reliably for any single story.
Useful phrase: "Points aren't a fixed hours-per-point ratio — velocity gives us a team-level trend over multiple sprints, not a guarantee for any individual ticket." This distinction is worth defending clearly, since misusing points as disguised hours undermines the whole practice.
5 / 6
Your team uses the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21) for story points instead of a linear scale (1, 2, 3, 4, 5...). How do you correctly explain why?
The Fibonacci-like scale's widening gaps reflect a real truth: estimation precision decreases as size increases. It's easy to distinguish a 1-point task from a 2-point task, but nearly impossible to meaningfully distinguish 20 points from 21 — so the scale forces a coarser (and more honest) bucket at larger sizes.
Useful phrase: "the widening gaps reflect that our confidence in exact size drops as complexity grows — so we deliberately use coarser buckets for bigger stories." This is also why very large stories ("13" or "21") are often a signal that the story should be broken down further before estimating precisely.
6 / 6
A team has just finished its first 3 sprints and wants to discuss "velocity" for the first time. Which explanation is correct?
Velocity is the team-level average of completed story points per sprint, calculated from historical sprints. It is used for planning ("based on our last 3 sprints averaging 24 points, we can likely commit to ~24 points next sprint") but should never be treated as a guaranteed capacity or, worse, a performance metric for individuals.
Useful phrase: "velocity is a forecasting tool based on trailing sprint history — it's noisy early on and should stabilise after several sprints." Using velocity to compare or pressure individual engineers is a well-known agile anti-pattern.
What does the "Story Point Vocabulary — Estimation Language Exercise" exercise cover?
Practise the vocabulary of story points, planning poker, T-shirt sizing, and velocity in professional English. 6 exercises for agile teams.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
How many questions are in "Story Point Vocabulary — Estimation Language Exercise"?
This exercise has 6 questions. Each one gives instant feedback with an explanation, so you can see exactly why an answer is right or wrong.
Do I need to create an account to save my progress?
No account is required. The progress bar and score are tracked in your browser for the current session -- the exercise is designed to be a quick, repeatable drill rather than something you resume later.
What happens if I get an answer wrong?
You'll see the correct answer highlighted immediately, along with a short explanation of why it's correct. Wrong answers aren't penalized beyond your score, and you can keep going through every question.
How is this exercise different from reading an article?
Articles explain vocabulary and concepts through prose, while exercises like this one are interactive drills -- multiple-choice questions -- that test and reinforce your recall of specific terms and phrasing.
Can I retry this exercise?
Yes -- use the "Try again" button on the results screen to reset your score and go through all the questions again from the start.
Where can I find more Estimation Language exercises?
Browse the full Estimation Language hub for related drills, or check the site-wide exercises index for other IT English topics.
Is this exercise suitable for beginners?
This exercise assumes basic familiarity with IT terminology. If a term feels unfamiliar, check the site Glossary for a plain-English definition before attempting the questions.
How often is new content like this published?
New exercises are added regularly across all categories, alongside new vocabulary sets and articles. Check back on the exercises hub to see what's new.