Sprint planning is the meeting where everything gets negotiated — scope, capacity, priorities, and timelines. It’s also the meeting where Vietnamese developers most often stay quiet when they should speak up.
The problem usually isn’t knowledge. You know the estimate is wrong. You know the scope is too large. You know adding “just one more feature” will break the sprint. What you don’t always have is the English to say it clearly and confidently in real time.
This post is the language toolkit for sprint planning conversations.
Defending Your Estimates
Estimates get challenged in sprint planning. “Can we bring this down?” is a standard question from product managers. How you respond in English determines whether the estimate holds or gets overridden without a real discussion.
When asked to reduce an estimate:
“I hear you on the timeline pressure. Let me walk you through what’s inside this estimate so we can see together where we might be able to compress.”
“That estimate includes [X, Y, Z]. If we want to bring it down, we’d need to descope one of those parts. Which would you want to cut?”
“The three points cover the happy path. There’s also error handling and the edge cases for [scenario]. If we’re comfortable calling those out-of-scope for now, I could see getting it to two points — but we’d need to revisit it next sprint.”
The pattern: never just defend the number. Walk through what’s inside it, then offer a trade. This turns “your estimate is wrong” into “what are you willing to give up?”
Raising Concerns About Scope
“Can we also add [feature]?” is how scope creep sounds in sprint planning. Your job as a tech lead or senior developer is to name what that addition costs.
“Adding that to this sprint would push us over capacity. We’re already at [X] points. What would you like to move out to make room?”
“That’s possible to add, but I want to flag the risk: it touches the same part of the code as [story], and there’s a conflict risk. If we add it without addressing that, we might create a dependency problem mid-sprint.”
“I’d rather keep this sprint focused and do [the new feature] properly next sprint than try to fit it in and deliver it half-finished.”
That last sentence is important to practice. “Half-finished” is better English than “not complete” in this context — it conveys the real risk.
Talking About Velocity and Capacity
When discussing how much the team can take on, precision in English matters. Vague answers invite pushback. Specific answers are much harder to argue with.
Weak: “We might be able to handle it.” Strong: “Our average velocity over the last four sprints is 34 points. This sprint I’d plan for 30 — two team members have PTO and we have the migration running in parallel.”
Weak: “That might take longer than you think.” Strong: “At our current velocity, that backlog would take roughly three sprints. If you want it in two, we need to either add capacity or reduce scope — and I’d want to understand which features are truly must-haves.”
Numbers anchor the conversation. “34 points” and “three sprints” are specific claims that require specific counter-arguments. “Might be able to handle it” invites someone to just say yes.
Handling “Just One More Thing”
“Just one more thing” is the most dangerous phrase in sprint planning. Here’s how to handle it without saying no and sounding obstructive.
“Happy to add it — let’s work out what it displaces. The sprint is full at [X] points. What would you like to deprioritize?”
“I want to be helpful here, but I also want to protect the team’s ability to actually finish what we commit to. Can we park that as the top item for next sprint?”
“What’s the priority between that and [existing story]? I can’t safely fit both — one of them needs to wait.”
The key technique: replace “no” with “what do you want to give up?” You’re not refusing — you’re making the trade-off explicit and putting the decision back with the person who’s asking.
Closing the Sprint and Setting Expectations
At the end of sprint planning, be explicit about the commitment and any risks. This protects the team and sets honest expectations.
“Just to confirm what we’re committing to: [list of stories]. We’re at [X] points, which is within our target range. The one risk I want to flag is [specific risk] — if that becomes a problem mid-sprint, I’ll let you know early.”
“We’re leaving [Y story] in the backlog — not because it isn’t important, but because I want us to finish what we start. It’ll be the first thing we pick up next sprint.”
“I want to be transparent: this is an aggressive sprint. We can do it, but there’s not a lot of buffer. If anything unexpected comes up, we’ll need to have a quick conversation about reprioritizing.”
🗣️ Key Phrases to Say Out Loud
-
“Let me WALK you THROUGH what’s INside this EStimate” /lɛt miː wɔːk juː θruː wɒts ˈɪnsaɪd ðɪs ˈɛstɪmɪt/ — Turns estimate defense into a collaborative walkthrough
-
“What would you LIKE to MOVE OUT to make ROOM?” /wɒt wʊd juː laɪk tə muːv aʊt tə meɪk ruːm/ — Forces explicit trade-off instead of scope addition
-
“I’d RATHER keep this SPRINT foCUSED” /aɪd ˈræðər kiːp ðɪs sprɪnt ˈfoʊkəst/ — Signals quality preference without sounding inflexible
-
“At our CURrent veˈLOCity, THAT would take ROUGHly three SPRINTS” /æt aʊər ˈkʌrənt vɪˈlɒsɪti ðæt wʊd teɪk ˈrʌfli θriː sprɪnts/ — Anchors timeline discussion with data, not opinion
-
“What’s the PRIority beˈTWEEN THAT and [story]?” /wɒts ðə praɪˈɒrɪti bɪˈtwiːn ðæt/ — Makes the choice explicit when both can’t fit
-
“I WANT to PROtect the TEAM’s aBILity to FINish what we comMIT to” /aɪ wɒnt tə prəˈtɛkt/ — Frames push-back as protection of delivery, not resistance
-
“I’ll let you KNOW EARLY if THAT CHANGES” /aɪl lɛt juː noʊ ˈɜːli ɪf ðæt ˈtʃeɪndʒɪz/ — Closes with a commitment to communicate — builds trust
📚 Vocabulary
1. Velocity /vɪˈlɒsɪti/
- Meaning: The average amount of work a team completes per sprint, measured in story points
- Example: “Our velocity has been consistent at 32–36 points for the last two months.”
2. Descope /diːˈskoʊp/ (verb)
- Meaning: To remove a feature or task from the current scope of work
- Example: “If we descope the notification feature, I can bring the estimate down by three points.”
3. Capacity /kəˈpæsɪti/
- Meaning: The amount of work a team can handle in a given time period
- Example: “We’re at 80% capacity this sprint with the two people on leave.”
4. Deprioritize /diːˈpraɪərɪtaɪz/ (verb)
- Meaning: To move something lower on the priority list
- Example: “If you want to add this, we need to deprioritize something else.”
5. Buffer /ˈbʌfər/
- Meaning: Extra capacity or time reserved for unexpected work
- Example: “We have no buffer this sprint — any new work will push something out.”
6. Commit /kəˈmɪt/ (verb, in Agile context)
- Meaning: To make a formal team agreement to deliver a set of stories in a sprint
- Example: “What are we actually committing to? I want that to be explicit before we finish planning.”
7. Scope creep /skoʊp kriːp/
- Meaning: The gradual expansion of project scope without adjustments to time, cost, or resources
- Example: “We’ve had significant scope creep this sprint — we added three stories after planning.”
🎯 Practice Now
Exercise 1: Estimate Defense Role-Play
Your PM says: “This story is estimated at 5 points. That seems high — can we get it to 3?”
Write your response using the “walk through what’s inside” technique. Then say it aloud.
Sample structure:
“Let me break down what’s in the five points. [2 points] is the API integration — that’s straightforward. [2 points] is the error handling: we need to cover the case where [X]. And [1 point] is the test coverage. If you’re comfortable cutting the error handling for now, I could see three — but we’d need to handle [X] properly before we ship to production.”
Exercise 2: Scope Creep Response
Your product manager says mid-sprint: “Can we also add the user preference screen this sprint? It shouldn’t take long.”
Practice saying this response aloud three times:
“I want to help make that happen. The sprint is currently at [X] points. If we add the preference screen, that’s another [Y] points — we’d need to move something out. The two smallest stories we have left are [A] and [B]. Would you want to push one of those to next sprint to make room?”
Exercise 3: Sprint Close Statement
Draft a one-minute closing statement for a sprint planning meeting. Include:
- What the team is committing to (2–3 stories)
- The sprint capacity and how close you are to it
- One risk you want to flag
- A commitment to early communication if things change
Say it aloud as if you’re addressing the full team. Time yourself — aim for under 90 seconds.
Sprint planning conversations are where tech leads earn credibility. If you consistently defend estimates with data, name trade-offs explicitly, and flag risks early — stakeholders learn to trust your judgment.
The English isn’t complicated. But it needs to be ready before the meeting starts.
Practice these phrases this week. Next sprint planning, you’ll have them when you need them.