Thuan: Sprint planning is where I feel most uncomfortable speaking English. It’s fast, people debate estimates, and I know the right answer but I can’t say it fast enough.
Alex: By the time you’ve formed your sentence, someone else has already moved the discussion forward?
Thuan: Exactly. So I stay quiet. Then we commit to a sprint scope that’s impossible. Then the team burns out. Then I blame myself for not speaking up.
Alex: That silence is expensive. Let’s give you the phrases you need so you can speak up instantly — no mental translation required.
The Sprint Planning Script
Thuan: Walk me through a typical sprint planning in English.
Alex: Sprint planning has four phases, and you need different language for each:
Phase 1: Reviewing the Backlog
The PO presents stories. Your job: ask clarifying questions.
| What You Need | Phrase |
|---|---|
| More context | ”Could you walk us through the user flow for this?” |
| Acceptance criteria | ”What does ‘done’ look like for this story?” |
| Edge cases | ”What should happen if [X]? The story doesn’t cover that.” |
| Dependencies | ”This depends on [X] — is that ready?” |
| Priority check | ”If we can only take 3 of these 5 stories, which are the must-haves?” |
Thuan: “What does ‘done’ look like?” — that’s a good one. Much better than what I usually say: “Can you explain more?”
Alex: “Can you explain more” is too vague. The PO doesn’t know what you don’t understand. Be specific.
Phase 2: Estimation Discussion
This is where it gets heated. Here are phrases for common scenarios:
Giving Your Estimate
- “I’d estimate this at [X] points. The main effort is [Y].”
- “This looks like a 5 to me. The API changes are straightforward, but the migration script might be risky.”
- “I’d say 8. There’s a lot of unknown here — we haven’t worked with this library before.”
Disagreeing With an Estimate
- “I think we’re underestimating this. The last time we did something similar, it took [X].”
- “I’d go higher — there’s hidden complexity in the [X] part.”
- “I’m not sure 2 is realistic. Can we break this down further?”
When You’re Not Sure
- “Honestly, I’m not sure about the estimate. Can we spike this first?”
- “I’d need to look at the existing code before I can estimate. Can we carry this to tomorrow?”
- “This one’s hard to estimate without more info. Could we time-box it at 3 days and reassess?”
Thuan: What’s a “spike” in English? My team uses it but I’ve never been confident about the meaning.
Alex: A spike is a time-boxed investigation. You don’t build anything — you research and come back with an answer. “Let’s spike this for half a day” means “let’s spend half a day investigating before we commit to an estimate.”
Phase 3: Committing to the Sprint
This is where tech leads need to protect their team:
Saying Yes (Confidently)
- “I’m comfortable committing to these stories for this sprint.”
- “This looks achievable. Let’s go for it.”
- “If we keep the scope as-is, we can deliver this.”
Pushing Back on Overload
- “I think we’re overcommitting. Our velocity last sprint was [X], and this is [Y] points.”
- “We can take stories 1 through 4, but story 5 would put us over capacity.”
- “I’d suggest we move [story] to the next sprint. We have [reason] that will eat into our time.”
- “If we add this, something else needs to come out. What’s the priority?”
The Magic Phrase: “What Should We Cut?”
Alex: This is the most powerful phrase in sprint planning. When someone pushes more scope:
“We can absolutely do this — but we’ll need to remove something else. Which of the current stories should we deprioritize?”
Thuan: That’s genius. You’re not saying no — you’re asking them to make the trade-off.
Alex: Exactly. You’re saying yes AND making the cost visible. This is how experienced tech leads protect their team without being confrontational.
Phase 4: Identifying Risks
- “One risk I see: [X] depends on [external team/API]. If they’re delayed, this story is blocked.”
- “We should flag that [person] is on leave next week. That reduces our capacity by [X]%.”
- “This story touches [critical system]. We should plan extra time for testing.”
- “I’d suggest we tackle the riskiest story first. If we discover surprises, we still have time.”
Real Sprint Planning Dialogue
Thuan: Can you show me a full example?
Alex: Here’s a realistic scene:
PO: Next up — the user notification preferences story. Users should be able to choose email, push, or both.
Thuan: Quick question — does this include the notification history page, or just the preference settings?
PO: Just the settings for now.
Thuan: Got it. And should the preferences sync across devices, or is it per-device?
PO: Good question. Let me check with the product team. For now, assume cross-device.
Dev: I’d estimate 3 points.
Thuan: I’d go with 5. Cross-device sync means we need to store preferences server-side, not in local storage. That adds API work and a migration.
PO: Makes sense. 5 it is. Can we fit it in?
Thuan: If we take this, we’re at 34 points — our velocity is 30. I’d suggest we move the analytics dashboard story to next sprint. It’s lower priority and the data pipeline isn’t ready anyway.
PO: Fair point. Let’s do that.
Thuan: That felt natural. I asked questions, adjusted the estimate with a reason, and pushed back with data.
Alex: That’s the pattern. Three ingredients: question, reason, alternative.
Vocabulary for Sprint Planning
| Term | Meaning | Example |
|---|---|---|
| Velocity | Average points completed per sprint | ”Our velocity is 28 points” |
| Capacity | Available team hours this sprint | ”We’re at 80% capacity — Minh is on leave” |
| Spike | Time-boxed research task | ”Let’s spike the OAuth integration first” |
| Carryover | Unfinished work from last sprint | ”We have 8 points of carryover” |
| Stretch goal | Nice-to-have if time allows | ”Let’s add this as a stretch goal” |
| Backlog grooming | Preparing stories before planning | ”This story needs more grooming” |
| T-shirt sizing | Rough estimation (S, M, L, XL) | “At a t-shirt size, this feels like an L” |
| Definition of Done | Criteria for “complete" | "Our DoD includes code review and QA signoff” |
Common Mistakes
Thuan: What mistakes do you see Asian tech leads make in sprint planning?
Alex: Three big ones:
1. Going Silent When You Disagree
In many Asian cultures, disagreeing with a PO or manager in a meeting feels rude. In Agile, it’s expected. If you disagree, speak up — politely but clearly:
❌ silence + then complaining to teammates after the meeting ✅ “I see it differently. Here’s my concern: [X].“
2. Over-Committing to Avoid Conflict
❌ “Yes, we can do all of it.” (when you know you can’t) ✅ “We can do stories 1-4 confidently. Story 5 is risky — can we mark it as a stretch goal?“
3. Explaining Too Much When Estimating
❌ A 3-minute technical explanation of why something is 5 points ✅ “I’d say 5 — the migration adds complexity. Happy to elaborate offline.”
10-Minute Self-Practice
Before Sprint Planning (5 min)
- Read through the backlog items
- For each story, write:
- Your estimate (one number)
- One risk or question
- One phrase from this post you’ll use
- Say your estimate out loud: “I’d estimate this at [X] because [reason].”
After Sprint Planning (5 min)
- Did you speak up? If not, why?
- Write down one thing you wanted to say but didn’t
- Practice saying it out loud — next time, you’ll be ready
Thuan: Simple enough. I can do this before every planning session.
Alex: Preparation beats fluency. A prepared B1 speaker is more effective than an unprepared C1 speaker.
What’s Next
Sprint planning covered. Next up: Refinement Meetings — where you ask the questions that prevent bad sprints in the first place. The art of “What about…?” in professional English.
This is Part 3 of the English Upgrade series — practical Business English for busy tech leads. See also English for Tech Leads Part 3: Meeting Mastery for broader meeting strategies.
Related: Tech Coffee Break #10: The System Design Interview — another scenario where clear English under pressure is essential.