5 exercises on sprint planning phrases. Choose the most natural and professional option.
0 / 12 completed
1 / 12
The team is assigning tickets and you want to take on a user authentication task. Which phrase sounds most natural?
"I CAN TAKE THAT ON": This is the standard phrase for volunteering in sprint planning. It's confident, brief, and the addition of context ("I've done similar work before") builds trust. Real examples: "I can take that on — it's related to what I shipped last sprint", "I can take that on — should be straightforward", "I can take that on if nobody else has it." Option A ("I will do") is grammatically fine but sounds like a declaration rather than a collaborative offer. Option C is overly formal. Option D ("I accept") sounds like a legal contract, not a team conversation.
2 / 12
Your team asks how long the API integration will take. You're not certain yet. Which estimate sounds most professional?
"I'D SAY ABOUT X, GIVE OR TAKE": This phrase signals a confident best-guess while acknowledging uncertainty. "Give or take" is a natural English qualifier that professional developers use constantly. Real examples: "I'd say about a week, give or take", "I'd say about half a sprint, give or take", "I'd say about two points, give or take — depends on the third-party docs." Option B ("I have no idea") is honest but unhelpful and sounds unprepared. Option C ("maybe two to five days") is too wide a range without context. Option D ("exactly three days") sounds overconfident and sets a risky expectation.
3 / 12
You've spotted a technical risk in a ticket before the sprint starts. What's the best way to flag it?
"I WANT TO FLAG A RISK EARLY — THIS TOUCHES X, WHICH HAS Y": Proactively naming the risk with a specific technical reason is exactly what senior engineers do in planning. Real examples: "I want to flag a risk early — this touches the legacy auth module, which hasn't been touched in two years", "I want to flag a risk early — this depends on the data team's pipeline being ready", "I want to flag a risk early — the acceptance criteria are ambiguous on the edge case." Options A and C are vague — they signal concern without identifying anything actionable. Option D ("just so you know") sounds like you're passing responsibility rather than contributing to de-risking.
4 / 12
You're not sure what a ticket is asking for. How do you ask for clarification during planning?
SPECIFIC CLARIFYING QUESTIONS: The best way to ask for clarification is to propose your interpretation with a concrete technical question — this shows you've engaged with the ticket and just need one thing confirmed. Real examples: "When you say 'fast', are we targeting under 200ms or is 2 seconds acceptable?", "Is this for all users or just admins?", "Should this work offline or can we assume connectivity?" Options A, C, and D all communicate confusion but offer nothing constructive. Option B immediately moves the conversation forward and demonstrates technical engagement, which is exactly what a planning session needs.
5 / 12
You're near your personal capacity for this sprint and someone is pushing to add another ticket. Which response handles this best?
"I'M PRETTY FULL THIS SPRINT, BUT IF WE DROP X, I COULD SQUEEZE IT IN": This phrase is collaborative rather than blunt — it acknowledges the constraint AND offers a trade-off path. Good engineers help the team solve capacity problems, not just block additions. Real uses: "I'm pretty full this sprint, but if we defer the refactor ticket, I could pick this up", "I'm pretty full this sprint, but if the estimates are smaller than I think, there might be room." Options A and C are honest but feel like closed doors. Option D ("impossible") sounds dramatic and absolute. The best response leaves room for negotiation while being clear about the constraint.
6 / 12
John from the UX team just commented on your PR: 'This needs a proper error handling strategy. It's returning a 404 without any context.' What's the most effective way to respond directly in the code review tool, acknowledging his concern and offering next steps?
The key here is to acknowledge the feedback constructively and propose a solution. Option 1 demonstrates responsiveness and outlines a concrete action. Options 2 and 3 are too vague or deflect responsibility, while option 4 ignores the critical comment. This shows you're actively listening and participating in the code review process.
7 / 12
During the standup, Mark says: 'I'm blocking on the database schema changes. The DBA team hasn't yet signed off.' What's the most appropriate way to respond in this situation, maintaining transparency and proactively managing the dependency?
This situation requires proactive management of dependencies. Option 3 demonstrates accountability by following up and seeking clarification, showing you're aware of potential roadblocks. Options 1 and 2 are passive and don't address the issue, while option 4 ignores the critical information shared during the standup.
8 / 12
Sarah from the frontend team is requesting you to estimate the effort for implementing a new notification system. She asks: 'Roughly how many story points should we assign?' Which response best demonstrates professional estimation during sprint planning?
Option A is unprofessional and lacks any estimation process. Option B offers a quick estimate but doesn't involve discussion or context. Option C is the most appropriate; it seeks clarification about scope before committing to an estimate – crucial for accurate planning. Option D provides an arbitrary number without justification.
9 / 12
David, the team lead, sends a Slack message: 'Hey team, let's aim to commit to no more than 3-5 new stories this sprint. Let's focus on finishing what we started.' You're considering taking on a small bug fix. Which phrase best reflects your approach?
Option A ignores the team lead's guidance and overcommits. Option B is a good question to ask for clarity on the definition of 'finished,' demonstrating a desire to understand expectations. Option C aligns with the team's capacity constraints, showing respect for agreed limits – this is key to sprint planning. Option D expresses resistance without offering a constructive solution.
10 / 12
You've just submitted a PR with several new API endpoints. The code reviewer, Emily, comments: 'This endpoint doesn't handle potential rate limiting. Consider adding retry logic.' What phrase best acknowledges the feedback and demonstrates commitment to addressing it?
Option A dismisses the feedback and lacks accountability. Option B shows a proactive approach to incorporating the suggestion, demonstrating responsiveness and technical understanding. Option C deflects responsibility inappropriately – developers own their code's error handling. Option D ignores valid concerns and potentially introduces vulnerabilities.
11 / 12
During the daily standup, Ben states: 'I'm still waiting for the authentication service to provide the updated API keys.' You realize this delay is impacting your progress. Which phrase best communicates your situation concisely and proactively?
Option A is overly dramatic and unproductive. Option B clearly explains the impact of the delay on your work, framing the issue directly. Option C shifts blame and avoids taking ownership. Option D demonstrates a lack of urgency and responsibility – important to avoid in standup updates.
12 / 12
You've already committed most of your story points for the sprint. Your manager asks: 'Can you take on this additional task – a small performance optimization?' Which response demonstrates appropriate capacity management?
Option A is a risky overcommitment that could jeopardize sprint goals. Option B politely declines the request while clearly stating your capacity constraints – essential for maintaining sprint focus. Option C suggests an unrealistic solution and avoids direct communication. Option D passes responsibility without providing a clear answer.
What will I practise in "Sprint Planning: Committing, Estimating & Capacity Phrases"?
This module focuses on Phrasebook — real workplace phrasing you'll use on the job. It contains 12 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 12 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.