📋 Backlog Refinement Language
Master the vocabulary for writing user stories, acceptance criteria, and splitting large backlog items. Intermediate
0 / 26 completed
1 / 26
During backlog refinement, the Product Owner presents four candidate user stories. The team needs to identify which one follows the correct user story format — describing a user goal rather than a technical implementation.
Which story is correctly written in the standard user story format?
The standard user story format is: "As a [role], I want [goal] so that [benefit]" — it describes what the user wants to achieve and why, not how the system or developer should build it.
| Option | Problem |
|---|---|
| B — collaborative filtering, 90% precision | Technical implementation detail — not negotiable, no user role or business value |
| C — "The system shall…" | System requirement format, not a user story — missing the human perspective and the "so that" benefit |
| D — "As a developer, I want…" | Developer role with a technical goal — not delivering user value; should be a tech task or spike |
Using the correct format matters: it keeps the team focused on outcomes for users, not outputs for engineers, and makes the story easier to slice and prioritise by business value.
2 / 26
The team is writing acceptance criteria for a session-expiry feature. The tech lead says: "Acceptance criteria must be in BDD format — Given, When, Then."
Which of the following is a correctly written BDD acceptance criterion?
BDD acceptance criteria use the Given / When / Then structure to describe behaviour from the user's perspective in a testable, unambiguous format:
| Clause | Role | Example |
|---|---|---|
| Given | Context / precondition | User has been inactive for 30 minutes |
| When | User action or system event | They navigate to a protected page |
| Then | Observable, verifiable outcome | Redirected to /login with a specific message |
Options A and B are test descriptions or requirements, not BDD criteria. Option C is informal notes — it lacks the structured format that allows direct automation and removes ambiguity for both developers and QA.
3 / 26
During a refinement session, the team applies the INVEST checklist to evaluate candidate stories. INVEST stands for: Independent, Negotiable, Valuable, Estimable, Small, Testable.
Which story satisfies all six INVEST criteria?
Option C — saving a delivery address — passes all six INVEST criteria:
| Criterion | Option A | Option B | Option C ✓ | Option D |
|---|---|---|---|---|
| Small | ❌ Entire UI redesign | ✓ | ✓ | ❌ Too vague |
| Negotiable | ✓ | ❌ Specifies OAuth 2.0 + JWT | ✓ | ✓ |
| Testable | ❌ No measurable criteria | ✓ | ✓ | ❌ "Good experience" not testable |
The key failures: A is too large (entire UI redesign = epic, not story), B pre-decides the technical implementation (violates Negotiable), and D is too vague to be Estimable or Testable.
4 / 26
During refinement, the tech lead says about a checkout story:
"This story is too large for one sprint. I suggest we split it into the happy path — where the payment goes through successfully — and separate stories for each error case: payment declined, address validation failure, and timeout."
Which story-splitting strategy is the tech lead describing?
Splitting by workflow scenarios (happy path + error cases) is one of the most valuable story-splitting strategies because each slice delivers independently testable user value:
| Splitting strategy | Value per slice | Recommended? |
|---|---|---|
| By workflow scenario (happy/error paths) | High — each slice is usable | ✓ Yes |
| By technical layer (UI / API / DB) | None — no layer works alone | ✗ Anti-pattern |
| By team member (component ownership) | None — creates integration risk | ✗ Anti-pattern |
| Cross-sprint (one large story) | None until fully done | ✗ Violates sprint goal clarity |
Technical layer splitting (Option A) is the most common anti-pattern — it creates component tasks that cannot independently deliver value to a user, which defeats the purpose of user stories.
5 / 26
During sprint planning, the Scrum Master adds a new item to the sprint backlog:
"Before we can estimate the payment gateway integration story, the team needs to investigate whether the vendor's API supports idempotent requests. I'm adding a spike to this sprint for that."
Which statement correctly defines a spike in Agile?
A spike is a time-boxed investigation task whose output is knowledge, not a shippable feature. Spikes reduce uncertainty and enable better estimation:
| Spike attribute | Description |
|---|---|
| Time-boxed | Has a fixed time limit (e.g. 4 hours, 1 day) to prevent unbounded research |
| Output is knowledge | Ends with a decision, recommendation, or updated estimate — not production code |
| Enables estimation | Run when a story cannot be estimated because of technical unknowns |
| Not a user story | Spikes do not follow the "As a user…" format; they are team-internal tasks |
Options B (urgent bug), C (performance test), and D (refactoring) describe different types of unplanned or technical work — none of them fits the definition of a spike.
6 / 26
Sarah, a junior developer, posts the following comment on Slack during a code review of a new API endpoint:
"Okay, this endpoint returns JSON. It's good because it's using the JSON.stringify() method. I think we should add more logging to capture the request details before sending them."Sarah's comment focuses on technical implementation details (JSON.stringify() and logging) rather than the user story or what the API is intended to achieve. The core problem here is that a good code review comment should relate back to the acceptance criteria of the user story – in this case, ensuring the endpoint delivers the correct data as defined by the requirements. The comment misses the opportunity to evaluate if the logging aligns with the goal of providing useful information for troubleshooting or monitoring.
7 / 26
PR Description:
During backlog refinement, the team is discussing a new feature – implementing two-factor authentication (2FA) for user logins. A developer submits a pull request with the following description:
"Implemented 2FA using TOTP. Added validation to ensure users have registered a device. Fixed a bug where users could bypass the 2FA prompt."
Which of the following PR descriptions would be most effective in communicating the work done to the Product Owner and reviewers, aligning with Agile principles?
The correct answer (option 1) provides a clear and concise description of the work done, using business language focused on the value delivered – enhancing security. The other options are too technical, lack context for the Product Owner, or fail to highlight the benefit of the feature. It's crucial in Agile that PR descriptions communicate *what* was achieved and *why* it matters, not just a list of technical steps, promoting shared understanding and faster feedback.
8 / 26
The team is refining the backlog for a new mobile app feature – 'Offline Content Access'. During the discussion, the Scrum Product Owner asks: 'Can you give me some examples of how we might break down this story into smaller, more manageable pieces?' Which approach would best align with Agile principles and facilitate effective refinement?
Remember to consider the value delivered at each step.
The correct answer focuses on breaking down the story into smaller, manageable user stories based on distinct functionalities. This aligns with Agile's iterative approach and allows for incremental value delivery – each story can be completed and tested independently. Options A and B are too broad, lacking specific deliverables and hindering progress. Option D is a technical specification, not a refined backlog item focused on the *user* experience.
9 / 26
During backlog refinement for a new e-commerce feature – 'Customer Reviews' – the team is discussing acceptance criteria. A developer suggests: "As a user, I want to be able to write a review so that I can share my opinion about the product." The Product Owner asks, 'This is good, but what specific details should we include in the acceptance criteria to ensure we're delivering value effectively?' Which of the following additions would best support this goal and align with Agile practices?
This scenario highlights the importance of detailed acceptance criteria in Agile. The correct option—'The review should include fields for rating (1-5 stars) and written comments.'—provides specific details that define *what* a successful user story looks like, ensuring clarity and measurable value delivery. Options A simply restates the user story; B introduces arbitrary constraints without defining value; and C focuses on technical integration rather than user benefit. Adding these specifics allows the team to verify they've met the requirement during testing.
10 / 26
Sarah, a junior developer, posts the following comment on Slack during a code review of a new API endpoint:
"Okay, this endpoint returns JSON. It's good because it's using the JSON.stringify() method. I think we should add more logging to capture the request details before sending them."Sarah's comment focuses on technical implementation details (JSON.stringify() and logging) rather than the user story or what the API is intended to achieve. The core problem here is that a good code review comment should relate back to the acceptance criteria of the user story – in this case, ensuring the endpoint delivers the correct data as defined by the requirements. The comment misses the opportunity to evaluate if the logging aligns with the goal of providing useful information for troubleshooting or monitoring.
11 / 26
PR Description:
During backlog refinement, the team is discussing a new feature – implementing two-factor authentication (2FA) for user logins. A developer submits a pull request with the following description:
"Implemented 2FA using TOTP. Added validation to ensure users have registered a device. Fixed a bug where users could bypass the 2FA prompt."
Which of the following PR descriptions would be most effective in communicating the work done to the Product Owner and reviewers, aligning with Agile principles?
The correct answer (option 1) provides a clear and concise description of the work done, using business language focused on the value delivered – enhancing security. The other options are too technical, lack context for the Product Owner, or fail to highlight the benefit of the feature. It's crucial in Agile that PR descriptions communicate *what* was achieved and *why* it matters, not just a list of technical steps, promoting shared understanding and faster feedback.
12 / 26
The team is refining the backlog for a new mobile app feature – 'Offline Content Access'. During the discussion, the Scrum Product Owner asks: 'Can you give me some examples of how we might break down this story into smaller, more manageable pieces?' Which approach would best align with Agile principles and facilitate effective refinement?
Remember to consider the value delivered at each step.
The correct answer focuses on breaking down the story into smaller, manageable user stories based on distinct functionalities. This aligns with Agile's iterative approach and allows for incremental value delivery – each story can be completed and tested independently. Options A and B are too broad, lacking specific deliverables and hindering progress. Option D is a technical specification, not a refined backlog item focused on the *user* experience.
13 / 26
During backlog refinement for a new e-commerce feature – 'Customer Reviews' – the team is discussing acceptance criteria. A developer suggests: "As a user, I want to be able to write a review so that I can share my opinion about the product." The Product Owner asks, 'This is good, but what specific details should we include in the acceptance criteria to ensure we're delivering value effectively?' Which of the following additions would best support this goal and align with Agile practices?
This scenario highlights the importance of detailed acceptance criteria in Agile. The correct option—'The review should include fields for rating (1-5 stars) and written comments.'—provides specific details that define *what* a successful user story looks like, ensuring clarity and measurable value delivery. Options A simply restates the user story; B introduces arbitrary constraints without defining value; and C focuses on technical integration rather than user benefit. Adding these specifics allows the team to verify they've met the requirement during testing.
14 / 26
Sarah, a junior developer, posts the following comment on Slack during a code review of a new API endpoint:
"Okay, this endpoint returns JSON. It's good because it's using the JSON.stringify() method. I think we should add more logging to capture the request details before sending them."Sarah's comment focuses on technical implementation details (JSON.stringify() and logging) rather than the user story or what the API is intended to achieve. The core problem here is that a good code review comment should relate back to the acceptance criteria of the user story – in this case, ensuring the endpoint delivers the correct data as defined by the requirements. The comment misses the opportunity to evaluate if the logging aligns with the goal of providing useful information for troubleshooting or monitoring.
15 / 26
PR Description:
During backlog refinement, the team is discussing a new feature – implementing two-factor authentication (2FA) for user logins. A developer submits a pull request with the following description:
"Implemented 2FA using TOTP. Added validation to ensure users have registered a device. Fixed a bug where users could bypass the 2FA prompt."
Which of the following PR descriptions would be most effective in communicating the work done to the Product Owner and reviewers, aligning with Agile principles?
The correct answer (option 1) provides a clear and concise description of the work done, using business language focused on the value delivered – enhancing security. The other options are too technical, lack context for the Product Owner, or fail to highlight the benefit of the feature. It's crucial in Agile that PR descriptions communicate *what* was achieved and *why* it matters, not just a list of technical steps, promoting shared understanding and faster feedback.
16 / 26
The team is refining the backlog for a new mobile app feature – 'Offline Content Access'. During the discussion, the Scrum Product Owner asks: 'Can you give me some examples of how we might break down this story into smaller, more manageable pieces?' Which approach would best align with Agile principles and facilitate effective refinement?
Remember to consider the value delivered at each step.
The correct answer focuses on breaking down the story into smaller, manageable user stories based on distinct functionalities. This aligns with Agile's iterative approach and allows for incremental value delivery – each story can be completed and tested independently. Options A and B are too broad, lacking specific deliverables and hindering progress. Option D is a technical specification, not a refined backlog item focused on the *user* experience.
17 / 26
During backlog refinement for a new e-commerce feature – 'Customer Reviews' – the team is discussing acceptance criteria. A developer suggests: "As a user, I want to be able to write a review so that I can share my opinion about the product." The Product Owner asks, 'This is good, but what specific details should we include in the acceptance criteria to ensure we're delivering value effectively?' Which of the following additions would best support this goal and align with Agile practices?
This scenario highlights the importance of detailed acceptance criteria in Agile. The correct option—'The review should include fields for rating (1-5 stars) and written comments.'—provides specific details that define *what* a successful user story looks like, ensuring clarity and measurable value delivery. Options A simply restates the user story; B introduces arbitrary constraints without defining value; and C focuses on technical integration rather than user benefit. Adding these specifics allows the team to verify they've met the requirement during testing.
18 / 26
Sarah, a junior developer, posts the following comment on Slack during a code review of a new API endpoint:
"Okay, this endpoint returns JSON. It's good because it's using the JSON.stringify() method. I think we should add more logging to capture the request details before sending them."Sarah's comment focuses on technical implementation details (JSON.stringify() and logging) rather than the user story or what the API is intended to achieve. The core problem here is that a good code review comment should relate back to the acceptance criteria of the user story – in this case, ensuring the endpoint delivers the correct data as defined by the requirements. The comment misses the opportunity to evaluate if the logging aligns with the goal of providing useful information for troubleshooting or monitoring.
19 / 26
PR Description:
During backlog refinement, the team is discussing a new feature – implementing two-factor authentication (2FA) for user logins. A developer submits a pull request with the following description:
"Implemented 2FA using TOTP. Added validation to ensure users have registered a device. Fixed a bug where users could bypass the 2FA prompt."
Which of the following PR descriptions would be most effective in communicating the work done to the Product Owner and reviewers, aligning with Agile principles?
The correct answer (option 1) provides a clear and concise description of the work done, using business language focused on the value delivered – enhancing security. The other options are too technical, lack context for the Product Owner, or fail to highlight the benefit of the feature. It's crucial in Agile that PR descriptions communicate *what* was achieved and *why* it matters, not just a list of technical steps, promoting shared understanding and faster feedback.
20 / 26
The team is refining the backlog for a new mobile app feature – 'Offline Content Access'. During the discussion, the Scrum Product Owner asks: 'Can you give me some examples of how we might break down this story into smaller, more manageable pieces?' Which approach would best align with Agile principles and facilitate effective refinement?
Remember to consider the value delivered at each step.
The correct answer focuses on breaking down the story into smaller, manageable user stories based on distinct functionalities. This aligns with Agile's iterative approach and allows for incremental value delivery – each story can be completed and tested independently. Options A and B are too broad, lacking specific deliverables and hindering progress. Option D is a technical specification, not a refined backlog item focused on the *user* experience.
21 / 26
During backlog refinement for a new e-commerce feature – 'Customer Reviews' – the team is discussing acceptance criteria. A developer suggests: "As a user, I want to be able to write a review so that I can share my opinion about the product." The Product Owner asks, 'This is good, but what specific details should we include in the acceptance criteria to ensure we're delivering value effectively?' Which of the following additions would best support this goal and align with Agile practices?
This scenario highlights the importance of detailed acceptance criteria in Agile. The correct option—'The review should include fields for rating (1-5 stars) and written comments.'—provides specific details that define *what* a successful user story looks like, ensuring clarity and measurable value delivery. Options A simply restates the user story; B introduces arbitrary constraints without defining value; and C focuses on technical integration rather than user benefit. Adding these specifics allows the team to verify they've met the requirement during testing.
22 / 26
During a daily standup, John mentions he's been refining the backlog for the 'User Profile Updates' feature. He says, 'We need to ensure we're adding sufficient detail to each story so that developers can accurately estimate the effort required.' What is John primarily referring to when discussing 'backlog refinement' in this context?
John is discussing refinement as the act of adding detail – acceptance criteria, estimates, and potentially breaking down larger stories. This is crucial because vague user stories lead to inaccurate estimations and ultimately, wasted development effort. Option A describes prioritization; C is creating new stories without context; and D represents simply assigning tasks.
23 / 26
Maria, a developer, is reviewing a PR for a new API endpoint. The PR description reads: 'This endpoint handles user authentication – it's pretty straightforward.' Which of the following best describes Maria's concern regarding this description?
Maria's concern stems from the lack of specifics. A good PR description should outline potential issues, security aspects, and how the code handles different scenarios. Simply stating it's 'straightforward' provides no valuable information for reviewers to assess its quality or identify potential problems. Option C is a tangential point about readability.
24 / 26
The team is discussing acceptance criteria for a story: 'Implement password reset functionality.' David suggests: 'As a user, I want to be able to request a password reset so that I can regain access to my account if I forget it.' Is this an example of a well-defined acceptance criterion?
David's suggestion is good because it uses the 'As a… I want… so that…' format which clearly outlines the user story's purpose. A strong acceptance criterion describes *what* the system should do and *why*, but doesn't dictate *how* it achieves that outcome – those are implementation details. Options B, C, and D miss this core element.
25 / 26
During a Slack conversation about a bug report related to user session timeouts, Sarah types: 'The server is sending an expired session cookie. We need to fix the timeout logic.' What does Sarah's comment primarily indicate?
Sarah's comment directly points to the source of the problem: an expired session cookie. This demonstrates her understanding of the technical issue and provides valuable information for debugging. Option A is too broad; C suggests a new task without investigation; and D is just stating the obvious.
26 / 26
The team is refining a backlog item: 'Improve website loading speed.' The Product Owner asks the development team, 'Can you provide some specific metrics – like PageSpeed Insights scores – to measure our progress?' What is the Product Owner primarily seeking when asking for these metrics?
The Product Owner is looking for measurable data – PageSpeed Insights scores – to objectively assess the effectiveness of their efforts. This allows them to track progress and demonstrate the value delivered against a concrete metric (website loading speed). Options A, C, and D are tangential or related to implementation details rather than measuring success.
Frequently Asked Questions
What will I practice in "Backlog Refinement Language | Agile & Scrum Exercises"?
This is an Agile & Scrum exercise set. It walks through 26 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 26 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.