4 exercises — clarifying user stories, Planning Poker language, raising sprint risks, and suggesting story splits.
0 / 19 completed
1 / 19
The Product Owner presents a user story: "As a user, I want to reset my password." There are no acceptance criteria. Which question best clarifies the story before the team estimates it?
Option B is ideal because it asks concrete, scoped questions rather than rejecting the story or making assumptions.
Why the other options fail: A — "Skip it" escalates conflict; it's better to ask clarifying questions to make the story ready. C — Assuming you know what to do is how scope creep happens. Password reset implementations vary widely. D — Asking about points before understanding requirements puts cart before horse; estimates are meaningless on an unclear story.
Good clarifying questions for user stories cover: 1. Acceptance criteria — "What does Done look like?" 2. Edge cases — "What happens if the user's email doesn't exist?" 3. Out of scope — "Is X in or out?" 4. Dependencies — "Does this need the email service to be set up first?"
Formula: "Can you define what 'done' looks like?" is a universal opener that invites the PO to write acceptance criteria in real time.
2 / 19
During Planning Poker, you're asked to estimate a refactoring task. You think it's more complex than others are saying. Which Planning Poker phrase expresses this professionally?
Option C models best practice in Planning Poker disagreements:
States a specific estimate: "8 points" — gives the team something concrete to discuss Explains the reasoning: Names the specific complexity drivers (migration, rollback, DBA coordination) Stays open to input: "Happy to be talked down if I'm missing something" — invites dialogue without being defensive
Why the others fail: A — Silent agreement with a wrong estimate isn't consensus; it's hiding a risk B — "You're all wrong" language is dismissive and shuts down conversation D — "I pass" without explanation gives the team nothing; it's the same as abstaining from a decision
Planning Poker language patterns: • "I'm going [X] because…" — explains your card choice • "My concern is…" — introduces a risk factor • "Am I the only one thinking about [X]?" — invites others to weigh in • "Can we split this into two stories?" — proposes a scope change • "I'd need to investigate [X] before I can estimate" — flags uncertainty honestly
3 / 19
The team has just agreed to take on a story you believe is too risky to deliver in this sprint. How do you raise the concern?
Option B is the correct approach. It follows a Risk → Specific Concern → Proposed Solution → Team Input structure:
Flags the risk professionally: "I want to flag a risk" — signals concern without alarm Specifies the actual risk: Third-party dependency + recent evidence (last week's downtime) — not vague fear Proposes two concrete options: Adjust acceptance criteria OR defer — gives the team a choice rather than a veto Invites dialogue: "What does the team think?" — keeps it collaborative
Why the others fail: A — "On the record" language creates defensiveness; it's passive-aggressive, not collaborative C — "Try and move it" normalizes failed sprint commitments; it undermines team predictability D — "Who approved this?" is accusatory; it attacks process instead of solving the problem
Sprint commitment language: "I want to flag a risk before we commit…" "My concern is our capacity — we already have X story points and…" "Are we comfortable with this dependency on [team/system/third party]?" "I'd suggest we buffer this with a stretch story rather than a commitment."
4 / 19
A user story is estimated at 21 story points — the team agrees it's too large for one sprint. How do you suggest splitting it?
Option B demonstrates a vertical slice split — the preferred technique for breaking down large stories without losing value:
Vertical slice: Each resulting story delivers end-to-end functionality (UI → API → DB) — just less of it. Users can actually use Story A while you build Story B.
Horizontal split (avoid): "Story A: build the database layer. Story B: build the UI." Neither story delivers value until both are done.
Common story-splitting patterns: • Happy path / edge cases — Build the core flow first; handle errors and exceptions next • CRUD split — Create + Read in Sprint 1; Update + Delete in Sprint 2 • Role split — Feature for registered users first; admin panel second • Performance split — Functional first; optimised second • Platform split — Desktop first; mobile responsive second
Why the others fail: A — "Half of it" is not a coherent story; what does half of "user account creation" even mean? C — Deferring solves nothing; backlog is where large stories go to be forgotten D — Re-estimating doesn't change the actual complexity; splitting does
5 / 19
Sarah (the Lead Developer) is reviewing a pull request for a new API endpoint. The PR description states: 'Implement the /users endpoint.' She notices the code doesn't include error handling for invalid input. Which of the following comments would be most effective in requesting changes?
The best approach is to directly state the issue and request a specific improvement. Option 1 uses inappropriate language. Option 2 is too vague. Option 3 clearly articulates the needed change. Option 4 shifts responsibility to post-deployment monitoring instead of addressing the immediate risk during development.
6 / 19
Mark (a junior developer) is participating in a Slack channel discussing sprint priorities. The team is debating whether to tackle a high-priority bug fix or implement a small new feature. Mark wants to express his preference for fixing the bug, believing it will have a more immediate impact. Which Slack message best communicates this while remaining collaborative?
Mark's opinion needs to be stated clearly but constructively. Option 1 is dismissive and doesn't justify his preference. Option 3 invites discussion – which is good, but Mark needs to state his view first. Option 4 avoids expressing a preference entirely, making the conversation less productive.
7 / 19
David (a senior developer) is writing a PR description for a code change that improves database query performance. The description currently reads: 'Optimized the SQL queries.' Which of the following additions would make the description more informative and useful to reviewers?
Providing quantifiable metrics (the 15% reduction) provides concrete evidence of the improvement and demonstrates its impact. Option 2 describes the *problem* being solved but not the solution. Option 3 details a technical implementation detail that's less important for reviewers to understand. Option 4 focuses on schema changes, which might be irrelevant to the specific PR.
8 / 19
Emily (a tester) notices a potential regression during a daily standup update. She wants to raise this issue without derailing the meeting. Which of the following statements would be the most appropriate way to do so?
Emily's statement should be factual and focused on the observation. Option 1 is alarmist and disruptive. Option 3 demands immediate action without context. Option 4 defers the issue – Emily needs to bring it to the team's attention now.
9 / 19
Tom (a developer) is discussing a story with the team. The initial estimate was 8 points, but after further discussion, he believes it's significantly more complex than initially assessed. Which statement best expresses this concern during a Planning Poker session?
Tom needs to directly communicate his revised assessment and suggest an adjustment to the estimate. Option 1 defends the original estimate without providing justification. Option 3 passively accepts a potentially incorrect estimate. Option 4 suggests revisiting assumptions – but Tom should lead this effort.
10 / 19
Sarah (the Lead Developer) is reviewing a pull request for a new API endpoint. The PR description states: 'Implement the /users endpoint.' She notices the code doesn't include error handling for invalid input. Which of the following comments would be most effective in requesting changes?
The best approach is to directly state the issue and request a specific improvement. Option 1 uses inappropriate language. Option 2 is too vague. Option 3 clearly articulates the needed change. Option 4 shifts responsibility to post-deployment monitoring instead of addressing the immediate risk during development.
11 / 19
Mark (a junior developer) is participating in a Slack channel discussing sprint priorities. The team is debating whether to tackle a high-priority bug fix or implement a small new feature. Mark wants to express his preference for fixing the bug, believing it will have a more immediate impact. Which Slack message best communicates this while remaining collaborative?
Mark's opinion needs to be stated clearly but constructively. Option 1 is dismissive and doesn't justify his preference. Option 3 invites discussion – which is good, but Mark needs to state his view first. Option 4 avoids expressing a preference entirely, making the conversation less productive.
12 / 19
David (a senior developer) is writing a PR description for a code change that improves database query performance. The description currently reads: 'Optimized the SQL queries.' Which of the following additions would make the description more informative and useful to reviewers?
Providing quantifiable metrics (the 15% reduction) provides concrete evidence of the improvement and demonstrates its impact. Option 2 describes the *problem* being solved but not the solution. Option 3 details a technical implementation detail that's less important for reviewers to understand. Option 4 focuses on schema changes, which might be irrelevant to the specific PR.
13 / 19
Emily (a tester) notices a potential regression during a daily standup update. She wants to raise this issue without derailing the meeting. Which of the following statements would be the most appropriate way to do so?
Emily's statement should be factual and focused on the observation. Option 1 is alarmist and disruptive. Option 3 demands immediate action without context. Option 4 defers the issue – Emily needs to bring it to the team's attention now.
14 / 19
Tom (a developer) is discussing a story with the team. The initial estimate was 8 points, but after further discussion, he believes it's significantly more complex than initially assessed. Which statement best expresses this concern during a Planning Poker session?
Tom needs to directly communicate his revised assessment and suggest an adjustment to the estimate. Option 1 defends the original estimate without providing justification. Option 3 passively accepts a potentially incorrect estimate. Option 4 suggests revisiting assumptions – but Tom should lead this effort.
15 / 19
Sarah (the Lead Developer) is reviewing a pull request for a new API endpoint. The PR description states: 'Implement the /users endpoint.' She notices the code doesn't include error handling for invalid input. Which of the following comments would be most effective in requesting changes?
The best approach is to directly state the issue and request a specific improvement. Option 1 uses inappropriate language. Option 2 is too vague. Option 3 clearly articulates the needed change. Option 4 shifts responsibility to post-deployment monitoring instead of addressing the immediate risk during development.
16 / 19
Mark (a junior developer) is participating in a Slack channel discussing sprint priorities. The team is debating whether to tackle a high-priority bug fix or implement a small new feature. Mark wants to express his preference for fixing the bug, believing it will have a more immediate impact. Which Slack message best communicates this while remaining collaborative?
Mark's opinion needs to be stated clearly but constructively. Option 1 is dismissive and doesn't justify his preference. Option 3 invites discussion – which is good, but Mark needs to state his view first. Option 4 avoids expressing a preference entirely, making the conversation less productive.
17 / 19
David (a senior developer) is writing a PR description for a code change that improves database query performance. The description currently reads: 'Optimized the SQL queries.' Which of the following additions would make the description more informative and useful to reviewers?
Providing quantifiable metrics (the 15% reduction) provides concrete evidence of the improvement and demonstrates its impact. Option 2 describes the *problem* being solved but not the solution. Option 3 details a technical implementation detail that's less important for reviewers to understand. Option 4 focuses on schema changes, which might be irrelevant to the specific PR.
18 / 19
Emily (a tester) notices a potential regression during a daily standup update. She wants to raise this issue without derailing the meeting. Which of the following statements would be the most appropriate way to do so?
Emily's statement should be factual and focused on the observation. Option 1 is alarmist and disruptive. Option 3 demands immediate action without context. Option 4 defers the issue – Emily needs to bring it to the team's attention now.
19 / 19
Tom (a developer) is discussing a story with the team. The initial estimate was 8 points, but after further discussion, he believes it's significantly more complex than initially assessed. Which statement best expresses this concern during a Planning Poker session?
Tom needs to directly communicate his revised assessment and suggest an adjustment to the estimate. Option 1 defends the original estimate without providing justification. Option 3 passively accepts a potentially incorrect estimate. Option 4 suggests revisiting assumptions – but Tom should lead this effort.
What will I practise in "Sprint Planning Language"?
This module focuses on Meetings & Collaboration — real workplace phrasing you'll use on the job. It contains 19 scenario-based multiple-choice questions with instant feedback.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account or sign-up required.
How many questions does this exercise have?
This module includes 19 questions. Each one gives an immediate right/wrong result plus a full explanation of the correct phrasing.
What happens if I answer a question incorrectly?
You'll see the correct answer highlighted straight away, along with a plain-English explanation of why it's right and why the other options don't fit — mistakes are part of the learning here.
Can I retry the exercise if I want a better score?
Yes — use the 'Try again' button on the results screen to reset your score and go through the questions again. There's no limit on attempts.
Who is this Meetings & Collaboration exercise for?
It's aimed at IT professionals with working English who want to sound more natural and precise around meetings & collaboration — useful whether you're preparing for real conversations at work or just building confidence with the vocabulary.
Do I need an account to track my progress?
No account is needed. Your progress through the exercise is tracked locally in your browser for the current session, and you can replay the module at any time.
How is this different from reading a blog article?
This exercise is an interactive drill that tests and reinforces specific phrasing through multiple-choice questions with instant feedback, while blog articles explain concepts and vocabulary in prose. The two work well together.
Where can I find more Meetings & Collaboration exercises?
See the Meetings & Collaboration hub for more modules like this one, or browse the full Exercises page for other IT-English topics.
Can I complete this exercise on my phone?
Yes — every exercise on CoderSlingo is fully responsive and works on phones and tablets, so you can practise anywhere.