5 exercises on sprint planning phrases. Choose the most natural and professional option.
0 / 5 completed
1 / 5
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 / 5
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 / 5
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 / 5
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 / 5
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.