Practise the IT-English vocabulary of agile estimation: story points, planning poker, relative sizing and reaching consensus.
0 / 27 completed
1 / 27
In planning poker, why do team members reveal their cards 'simultaneously'?
Revealing at the same time prevents 'anchoring', where an early number sways everyone else's estimate.
2 / 27
Story points measure 'relative complexity'. What does that mean?
Story points express relative effort/complexity versus a baseline story, not concrete hours.
3 / 27
Two estimates are far apart, so the team 'discusses the spread'. What is happening?
Discussing the spread surfaces differing assumptions and risks before the team re-estimates toward consensus.
4 / 27
Which sentence correctly uses 'baseline story'?
A baseline (reference) story is a well-understood item used as the yardstick for relative estimation.
5 / 27
Someone plays a '?' card in planning poker. What does it signal?
A '?' means the estimator doesn't have enough information yet and the story needs more clarity.
6 / 27
Sarah: 'Okay team, we're estimating the new user onboarding flow. I'm going to say 8 points.'
David: 'Hmm, that seems a little high. I was thinking around 5.'
Maria: 'I agree with David – it feels like a bit of a stretch considering the existing integrations we're building in.'
Which of the following best describes what Maria is doing when she offers a different estimate?
Maria is engaging in 'challenging' behavior, which is a crucial part of Planning Poker. She isn't just agreeing; she's actively questioning Sarah's initial estimate and providing a rationale for her own lower point value – this demonstrates critical thinking and helps the team identify potential misunderstandings or areas where the task might be more complex than initially assumed. The other options misrepresent the dynamic of collaborative estimation, which relies on open discussion and differing perspectives.
7 / 27
PR Description: 'Implementing the new user onboarding flow. Initial estimate was 8 points based on a simple registration form. David and Maria have raised concerns about integration complexity with existing services. Please review.'
During a code review discussion, Maria's comment, 'It feels like a bit of a stretch considering the existing integrations we're building in,' is primarily aimed at:
Maria isn't dismissing the original estimate; she's prompting a deeper discussion. The phrase 'feels like a bit of a stretch' indicates she wants to understand *why* it was initially estimated at 8 points, specifically regarding potential complexities she identifies. This is a crucial step in planning poker - collaboratively refining estimates by uncovering hidden assumptions and dependencies, not simply rejecting the initial suggestion. Option A is too aggressive; option C represents a more thorough investigation, and options B & D are unnecessary levels of confrontation.
8 / 27
During a code review discussion, Maria's comment, 'It feels like a bit of a stretch considering the existing integrations we're building in,' is primarily aimed at:
highlighting potential technical debtrequesting clarification on the acceptance criteriasuggesting a more detailed breakdown of the taskconfirming the team's understanding of the user story
Maria's comment isn't just about agreeing or disagreeing; it's a direct challenge to the initial estimate. She's using the phrase 'feels like a stretch' to signal that the original estimation doesn't adequately account for the added complexity introduced by the existing integrations—a core principle of Planning Poker, which is about relative sizing based on perceived effort. The incorrect options represent misunderstandings of what 'feeling' like a stretch means within this context; it implies an adjustment due to unseen factors.
9 / 27
Slack Message: 'Hey team, @john_doe just played a ? card during planning poker for the new API endpoint. Anyone want to discuss why he chose that? During a Slack conversation about the API estimation, what is John's ? card most likely signaling?
The '?' card in planning poker almost always indicates ambiguity or a lack of shared understanding. John isn't necessarily stating his opinion on the effort; he's signaling that there's something missing from the story definition – perhaps unclear acceptance criteria, missing dependencies, or an incomplete understanding of the scope. It prompts discussion to resolve this uncertainty before proceeding with the estimate.
10 / 27
Sarah: 'Okay team, we're estimating the new user onboarding flow. I'm going to say 8 points.'
David: 'Hmm, that seems a little high. I was thinking around 5.'
Maria: 'I agree with David – it feels like a bit of a stretch considering the existing integrations we're building in.'
Which of the following best describes what Maria is doing when she offers a different estimate?
Maria is engaging in 'challenging' behavior, which is a crucial part of Planning Poker. She isn't just agreeing; she's actively questioning Sarah's initial estimate and providing a rationale for her own lower point value – this demonstrates critical thinking and helps the team identify potential misunderstandings or areas where the task might be more complex than initially assumed. The other options misrepresent the dynamic of collaborative estimation, which relies on open discussion and differing perspectives.
11 / 27
PR Description: 'Implementing the new user onboarding flow. Initial estimate was 8 points based on a simple registration form. David and Maria have raised concerns about integration complexity with existing services. Please review.'
During a code review discussion, Maria's comment, 'It feels like a bit of a stretch considering the existing integrations we're building in,' is primarily aimed at:
Maria isn't dismissing the original estimate; she's prompting a deeper discussion. The phrase 'feels like a bit of a stretch' indicates she wants to understand *why* it was initially estimated at 8 points, specifically regarding potential complexities she identifies. This is a crucial step in planning poker - collaboratively refining estimates by uncovering hidden assumptions and dependencies, not simply rejecting the initial suggestion. Option A is too aggressive; option C represents a more thorough investigation, and options B & D are unnecessary levels of confrontation.
12 / 27
During a code review discussion, Maria's comment, 'It feels like a bit of a stretch considering the existing integrations we're building in,' is primarily aimed at:
highlighting potential technical debtrequesting clarification on the acceptance criteriasuggesting a more detailed breakdown of the taskconfirming the team's understanding of the user story
Maria's comment isn't just about agreeing or disagreeing; it's a direct challenge to the initial estimate. She's using the phrase 'feels like a stretch' to signal that the original estimation doesn't adequately account for the added complexity introduced by the existing integrations—a core principle of Planning Poker, which is about relative sizing based on perceived effort. The incorrect options represent misunderstandings of what 'feeling' like a stretch means within this context; it implies an adjustment due to unseen factors.
13 / 27
Slack Message: 'Hey team, @john_doe just played a ? card during planning poker for the new API endpoint. Anyone want to discuss why he chose that? During a Slack conversation about the API estimation, what is John's ? card most likely signaling?
The '?' card in planning poker almost always indicates ambiguity or a lack of shared understanding. John isn't necessarily stating his opinion on the effort; he's signaling that there's something missing from the story definition – perhaps unclear acceptance criteria, missing dependencies, or an incomplete understanding of the scope. It prompts discussion to resolve this uncertainty before proceeding with the estimate.
14 / 27
Sarah: 'Okay team, we're estimating the new user onboarding flow. I'm going to say 8 points.'
David: 'Hmm, that seems a little high. I was thinking around 5.'
Maria: 'I agree with David – it feels like a bit of a stretch considering the existing integrations we're building in.'
Which of the following best describes what Maria is doing when she offers a different estimate?
Maria is engaging in 'challenging' behavior, which is a crucial part of Planning Poker. She isn't just agreeing; she's actively questioning Sarah's initial estimate and providing a rationale for her own lower point value – this demonstrates critical thinking and helps the team identify potential misunderstandings or areas where the task might be more complex than initially assumed. The other options misrepresent the dynamic of collaborative estimation, which relies on open discussion and differing perspectives.
15 / 27
PR Description: 'Implementing the new user onboarding flow. Initial estimate was 8 points based on a simple registration form. David and Maria have raised concerns about integration complexity with existing services. Please review.'
During a code review discussion, Maria's comment, 'It feels like a bit of a stretch considering the existing integrations we're building in,' is primarily aimed at:
Maria isn't dismissing the original estimate; she's prompting a deeper discussion. The phrase 'feels like a bit of a stretch' indicates she wants to understand *why* it was initially estimated at 8 points, specifically regarding potential complexities she identifies. This is a crucial step in planning poker - collaboratively refining estimates by uncovering hidden assumptions and dependencies, not simply rejecting the initial suggestion. Option A is too aggressive; option C represents a more thorough investigation, and options B & D are unnecessary levels of confrontation.
16 / 27
During a code review discussion, Maria's comment, 'It feels like a bit of a stretch considering the existing integrations we're building in,' is primarily aimed at:
highlighting potential technical debtrequesting clarification on the acceptance criteriasuggesting a more detailed breakdown of the taskconfirming the team's understanding of the user story
Maria's comment isn't just about agreeing or disagreeing; it's a direct challenge to the initial estimate. She's using the phrase 'feels like a stretch' to signal that the original estimation doesn't adequately account for the added complexity introduced by the existing integrations—a core principle of Planning Poker, which is about relative sizing based on perceived effort. The incorrect options represent misunderstandings of what 'feeling' like a stretch means within this context; it implies an adjustment due to unseen factors.
17 / 27
Slack Message: 'Hey team, @john_doe just played a ? card during planning poker for the new API endpoint. Anyone want to discuss why he chose that? During a Slack conversation about the API estimation, what is John's ? card most likely signaling?
The '?' card in planning poker almost always indicates ambiguity or a lack of shared understanding. John isn't necessarily stating his opinion on the effort; he's signaling that there's something missing from the story definition – perhaps unclear acceptance criteria, missing dependencies, or an incomplete understanding of the scope. It prompts discussion to resolve this uncertainty before proceeding with the estimate.
18 / 27
Sarah: 'Okay team, we're estimating the new user onboarding flow. I'm going to say 8 points.'
David: 'Hmm, that seems a little high. I was thinking around 5.'
Maria: 'I agree with David – it feels like a bit of a stretch considering the existing integrations we're building in.'
Which of the following best describes what Maria is doing when she offers a different estimate?
Maria is engaging in 'challenging' behavior, which is a crucial part of Planning Poker. She isn't just agreeing; she's actively questioning Sarah's initial estimate and providing a rationale for her own lower point value – this demonstrates critical thinking and helps the team identify potential misunderstandings or areas where the task might be more complex than initially assumed. The other options misrepresent the dynamic of collaborative estimation, which relies on open discussion and differing perspectives.
19 / 27
PR Description: 'Implementing the new user onboarding flow. Initial estimate was 8 points based on a simple registration form. David and Maria have raised concerns about integration complexity with existing services. Please review.'
During a code review discussion, Maria's comment, 'It feels like a bit of a stretch considering the existing integrations we're building in,' is primarily aimed at:
Maria isn't dismissing the original estimate; she's prompting a deeper discussion. The phrase 'feels like a bit of a stretch' indicates she wants to understand *why* it was initially estimated at 8 points, specifically regarding potential complexities she identifies. This is a crucial step in planning poker - collaboratively refining estimates by uncovering hidden assumptions and dependencies, not simply rejecting the initial suggestion. Option A is too aggressive; option C represents a more thorough investigation, and options B & D are unnecessary levels of confrontation.
20 / 27
During a code review discussion, Maria's comment, 'It feels like a bit of a stretch considering the existing integrations we're building in,' is primarily aimed at:
highlighting potential technical debtrequesting clarification on the acceptance criteriasuggesting a more detailed breakdown of the taskconfirming the team's understanding of the user story
Maria's comment isn't just about agreeing or disagreeing; it's a direct challenge to the initial estimate. She's using the phrase 'feels like a stretch' to signal that the original estimation doesn't adequately account for the added complexity introduced by the existing integrations—a core principle of Planning Poker, which is about relative sizing based on perceived effort. The incorrect options represent misunderstandings of what 'feeling' like a stretch means within this context; it implies an adjustment due to unseen factors.
21 / 27
Slack Message: 'Hey team, @john_doe just played a ? card during planning poker for the new API endpoint. Anyone want to discuss why he chose that? During a Slack conversation about the API estimation, what is John's ? card most likely signaling?
The '?' card in planning poker almost always indicates ambiguity or a lack of shared understanding. John isn't necessarily stating his opinion on the effort; he's signaling that there's something missing from the story definition – perhaps unclear acceptance criteria, missing dependencies, or an incomplete understanding of the scope. It prompts discussion to resolve this uncertainty before proceeding with the estimate.
22 / 27
David during a standup update said: 'For the new authentication service, I'm estimating 6 story points. It involves implementing JWTs and OAuth flows.' Maria responds, 'That seems ambitious – are we factoring in potential rate limiting challenges or complex user flow validation?' What is Maria's primary concern regarding David's estimate?
Maria isn't directly criticizing the technical choices. Instead, she's raising a crucial question about potential risks – rate limiting and complex validation are common challenges with authentication services that often get overlooked in initial estimates. The incorrect options focus on scope reduction or design details rather than proactively addressing potential issues during estimation.
23 / 27
During a standup update, Alex says: 'We're estimating the new reporting dashboard at 7 points. It includes data aggregation from multiple microservices.' Ben replies with: 'Seven? That seems high given the potential for performance bottlenecks when querying those services. What is Ben primarily trying to achieve with this comment?'
Ben's response isn't about agreeing or disagreeing with the initial estimate. Instead, he's proactively identifying a potential problem – performance bottlenecks due to data aggregation – and signaling that this needs further scrutiny during the planning process. This demonstrates an understanding of risk mitigation within story estimation.
24 / 27
In a Slack channel discussing an API endpoint estimate, Liam posts: '@jane_smith just put down a 3 card. Anyone have thoughts on why she chose that low number?' What is the *primary* purpose of Liam's message?
Liam is explicitly asking for *reasons* behind Jane's card choice. This isn't about confirming understanding or challenging the number itself; it's about uncovering the thought process and potential assumptions driving the estimate. This is a key part of collaborative planning poker.
25 / 27
Sarah writes in a PR description: 'Implementing user profile updates. Initial estimate: 5 points. This includes updating the database and sending notifications.' David comments: 'That seems optimistic. I'm concerned about potential race conditions during concurrent updates.' What is David's main concern?
David isn't questioning the *number* of points (5). He's raising a critical concern about potential problems – race conditions – that could significantly impact the quality and reliability of the implementation. This highlights the importance of considering technical risks during story estimation.
26 / 27
During a code review, Emily says: 'Considering the need to integrate with the legacy billing system, this feels like a significant effort. It's adding substantial complexity.' What is Emily's statement *primarily* focused on?
Emily is highlighting the *increased risk* associated with integrating with a legacy system. Legacy systems are often complex, poorly documented, and prone to unexpected issues – this statement is a direct expression of that concern and implicitly suggests the task might require more planning or resources.
27 / 27
In a Slack channel discussing an API design, Mark says: '@paul_jones just played a 9 card. Anyone want to discuss the assumptions behind that estimate?' Paul responds: 'I was focusing on the anticipated load and the need for robust error handling.' What is Paul primarily communicating?
Paul is explaining *why* he chose the card. He's detailing the key factors—anticipated load and robust error handling—that drove his estimate. This demonstrates a transparent approach to planning poker and allows others to understand the reasoning behind the chosen value.
What will I practice in "Story Estimation & Planning Poker"?
This is an Agile & Scrum exercise set. It walks through 27 scenario-based multiple-choice questions built around real usage of Agile & Scrum terminology that IT professionals encounter on the job.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to complete with no account, sign-up, or paywall.
How many questions are in this exercise?
This set contains 27 questions. Each one shows immediate feedback and a detailed explanation after you answer, so you learn the correct usage right away rather than waiting for a final score.
Do I need prior experience to complete this exercise?
No prior experience is required. Each question includes a full explanation covering the reasoning behind the correct answer, so the exercise itself teaches the Agile & Scrum vocabulary as you go.
Can I retry the exercise if I get questions wrong?
Yes — use the "Try again" button on the results screen to reset your answers and go through all the questions again. There is no limit on attempts.
Is my progress saved?
Your answers and score for the current session are tracked in the browser as you go. No account or login is needed, and there is nothing to install.
What if I don't understand a term used in a question?
Read the explanation shown after you answer each question — it breaks down the correct term in plain English with a real-world example. You can also check the site Glossary for quick definitions.
How is this different from reading a blog article on the topic?
Exercises like this one are interactive drills that test and reinforce specific vocabulary through multiple-choice questions, while blog articles explain concepts in prose. Practising here after reading builds active recall, not just passive recognition.
Where can I find more Agile & Scrum exercises?
See the Agile & Scrum exercises hub for the full set of related pages, or browse all exercise categories from the main Exercises index.
Can I use this exercise to prepare for a technical interview?
Yes — Agile & Scrum vocabulary comes up often in technical discussions and interviews. Pair this exercise with our dedicated Interview Preparation section for role-specific practice.