5 exercises on backlog refinement and story grooming phrases. Choose the most natural and professional option.
0 / 10 completed
1 / 10
A user story lacks enough information for the team to point it accurately. Which phrase professionally flags this?
This story needs more detail before we can estimate it: This phrase clearly links the lack of information to a concrete consequence — the team cannot estimate — and frames the issue constructively rather than as a complaint. It is professional, actionable, and invites the product owner to provide clarification. Option A is informal and vague. Option B sounds dismissive and doesn't specify what would help. Option D implies blame ("someone needs to explain") without being constructive. In refinement sessions, flagging stories that are not "ready" for estimation — using objective criteria like lack of detail — is the team's shared responsibility.
2 / 10
A user story covers too many things and would take several weeks. What is the standard agile suggestion?
Can we split this into smaller tickets? Story splitting is a core backlog refinement technique — large stories (sometimes called epics) are broken into smaller, independently deliverable user stories that fit within a single sprint. Using "split" and "tickets" is the idiomatic agile vocabulary. Option B correctly identifies the problem but doesn't suggest a solution — the point of refinement is to act on the finding. Option C is vague ("at some point") and defers action. Option D describes the problem without proposing splitting. Asking "can we split?" also invites collaboration and positions the work as a team effort rather than a criticism.
3 / 10
You need to clarify the exit criteria for a story before the team can start it. Which phrasing is most professional?
What's the acceptance criteria? Acceptance criteria (AC) are the specific, testable conditions a user story must satisfy to be accepted by the product owner. They are a formal agile concept, distinct from the Definition of Done, and are usually written as "Given / When / Then" or bullet-point conditions. Using the correct term connects the question to a specific deliverable — written AC — that the team can reference during development and QA. Option A is informal and vague. Option B focuses on authorship rather than the story's requirements. Option C asks about testing specifically, which is narrower than acceptance criteria. "What's the acceptance criteria?" is direct, precise, and universally understood in agile teams.
4 / 10
One story cannot be started until another team delivers an API. How do you raise this in refinement?
This is a dependency — should we block it? "Dependency" is the precise agile term for a relationship where one piece of work relies on another before it can proceed. Marking a story as "blocked" in the backlog is a formal action — it signals to stakeholders that work cannot begin until the dependency is resolved. This phrase does two things: names the issue correctly (dependency) and prompts a team decision (should we block it?). Option A is informal and slightly adversarial. Option C defers the discussion without naming the dependency. Option D uses the right word but frames it negatively without proposing action. Naming dependencies explicitly in refinement prevents surprises in sprint planning.
5 / 10
A story is currently scheduled for this sprint but the team agrees it should wait. What is the professional way to say this?
I'd reprioritise this to next sprint: "Reprioritise" is the correct agile vocabulary for deliberately changing the order or timing of backlog items. It is an active, ownership-taking phrase — "I'd reprioritise" signals a clear recommendation with a specific outcome (next sprint). Option A is factual but passive and doesn't suggest a concrete action. Option B is informal ("push back") and vague about timing. Option D is dismissive and suggests the story might be forgotten rather than deliberately scheduled. In backlog refinement, reprioritisation decisions should be explicit and time-bound — "next sprint" gives the team and product owner a clear expectation of when the work will be reconsidered.
6 / 10
During a code review, Alex comments: 'This story needs more detail about the expected user interaction.' Which phrase best reflects this concern in a professional context?
The key here is requesting clarification. 'Can you elaborate on the user flow?' directly asks for more information about a critical aspect of the story. The other options are dismissive or offer unhelpful feedback. A good code review focuses on actionable improvements and understanding requirements.
7 / 10
Sarah is drafting a Slack message to the product owner: 'We're looking at tackling this new payment integration story. It's going to need a significant amount of time – potentially two sprints – to fully implement and test.' What's the most appropriate way to phrase this within a backlog refinement meeting?
Sarah is accurately estimating the effort. Framing it as 'approximately 2 weeks' provides a realistic expectation and avoids over-promising. The other options are either overly optimistic or shift blame without providing concrete information about scope or complexity.
8 / 10
You're reviewing a Pull Request description for a story related to user authentication. The description states: 'Implement login.' What's the most effective addition to improve clarity and ensure the developer understands the scope?
Providing specific details about the expected functionality – 'The user should be able to log in with their email address' – dramatically reduces ambiguity. The other options are either too vague or add unrelated requirements. A good PR description defines what is required.
9 / 10
During a standup update, David says: 'We're blocked on the API from Team Alpha for the user profile integration story. We can't start development until we have that.' How should David best communicate this to the team during refinement?
David needs to clearly articulate the dependency. 'We need the API before we proceed' directly highlights the blocking factor and prompts discussion about mitigation strategies. The other options are unproductive or attempt to circumvent the problem.
10 / 10
The team has decided to postpone a story for this sprint due to shifting priorities. Maria says: 'Let's put this back in the backlog and revisit it next week.' What is the most professional way to communicate this decision within the refinement session?
Acknowledging the need for additional time is crucial. 'We need more time for this story' provides a clear rationale and opens the door for further discussion about prioritization and scope adjustment. The other options are dismissive or deflect responsibility.
What will I practise in "Backlog Refinement: Grooming & Prioritising Stories"?
This module focuses on Phrasebook — real workplace phrasing you'll use on the job. It contains 10 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 10 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 Phrasebook exercise for?
It's aimed at IT professionals with working English who want to sound more natural and precise around phrasebook — 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 Phrasebook exercises?
See the Phrasebook 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.