Sprint Planning and Estimation Meeting English Expression Guide

• Introduction
• Opening a Sprint Planning Meeting
  • The Opening and Setting the Sprint Goal
  • Checking Team Capacity
  • Discussing Velocity
  • Real Dialogue 1: Opening Sprint Planning
• Discussing Story Point Estimates
  • Running Planning Poker
  • Explaining a Difference in Estimates
  • Proposing a Story Split
  • Real Dialogue 2: A Planning Poker Debate
• Communicating Technical Debt
  • Reporting Technical Debt
  • Conversation Patterns With the Product Owner
  • Real Dialogue 3: Explaining Technical Debt to the PO
• Backlog Refinement Expressions
  • Checking the Definition of Ready
  • Discussing Acceptance Criteria
  • Identifying Dependencies
  • Real Dialogue 4: Backlog Refinement
• Disagreeing Professionally
  • Five Polite Ways to Disagree
  • Patterns for Proposing an Alternative
  • Expressions for Reaching Consensus
• Notes for Non-Native Speakers
  • Commitment vs Forecast
  • Output vs Outcome
  • Complex vs Complicated
  • The Strength of Must / Should / Could
• Common Abbreviations and Idioms
• Closing the Meeting
  • Wrapping Up the Action Items
  • Confirming Next Steps and Closing
• Full Scenario: A Complete Sprint Planning Conversation
  • Real Dialogue 5: The Full Planning Script
• References

Introduction

Sprint planning and estimation meetings are where an agile team's core decisions get made. For a non-native English speaker on a global team, they carry a particular challenge. You have to express a technical judgment quickly in English, disagree politely with a colleague's estimate, and explain the severity of technical debt to people who are not engineers.

The difficulties Korean developers actually hit are these.

• Giving only a number in planning poker, without explaining the reasoning behind the estimate
• Failing to frame technical debt around business impact when explaining it to the Product Owner
• Failing to turn a difference in estimates into a constructive discussion
• Failing to pin the action items down clearly as the meeting closes

This article organizes the English you need at each stage of sprint planning, from the opening through the close, and puts it into real dialogue you can use immediately. Every expression comes with a note on what it does, so it also works as a quick skim right before a meeting.

Opening a Sprint Planning Meeting

How the meeting opens sets the tone for everything after it. Here are the expressions you need whether you are running it as Scrum Master or team lead, or taking part as a team member.

The Opening and Setting the Sprint Goal

[Opening the meeting]

"Alright everyone, let's kick off our sprint planning for Sprint 24."
("Kick off" is the natural verb here; "let's start" sounds flatter.)

"Before we dive into the backlog, let's align on the sprint goal."
(Aligns on the goal before anyone opens the backlog.)

"The Product Owner has proposed the following sprint goal:
deliver the checkout optimization feature to staging."
(States the proposed goal as one concrete deliverable.)

"Does anyone have concerns about this sprint goal?"
(Invites objections before the goal gets locked in.)

Checking Team Capacity

[Capacity check]

"Let's do a quick capacity check. Any PTO or reduced availability
this sprint?"
(Asks about PTO and reduced availability in a single line.)

"I'll be out on Thursday and Friday, so my capacity is about
60 percent this sprint."
(Gives dates and a percentage instead of just "I'll be out.")

"We also have the on-call rotation — Sarah is primary on-call
this sprint."
(On-call is capacity too, and it belongs in this check.)

Discussing Velocity

[Velocity discussion]

"Let's start by reviewing our velocity from the last sprint."
(Starts from the data rather than from opinion.)

"Our average velocity over the last three sprints has been 42 points."
(A three-sprint average is the usual baseline.)

"Given the reduced capacity, I'd suggest we plan for about
35 points this sprint."
(Adjusts the plan down for the capacity that was just reported.)

"Keep in mind that velocity is a forecast, not a commitment."
(The line that stops velocity from turning into a promise.)

Real Dialogue 1: Opening Sprint Planning

[Setting: Alex, the Scrum Master, opens sprint planning]

Alex (Scrum Master):
  "Good morning, team. Let's kick off Sprint 24 planning.
   First, a quick capacity check — any time off or
   reduced availability?"

You (Developer):
  "I have a dentist appointment on Wednesday afternoon,
   but otherwise I'm fully available."

Sarah (Developer):
  "I'm primary on-call this sprint, so I'd say my capacity
   is about 80 percent."

Alex:
  "Noted. Our velocity last sprint was 45 points, and
   the three-sprint average is 42. With Sarah's reduced
   capacity, I'd suggest we target around 38 points.
   Does that feel reasonable?"

You:
  "That sounds about right. We also carried over two
   unfinished stories from last sprint, so we should
   factor those in first."

Alex:
  "Great point. Let's pull those in and then look at
   the prioritized backlog."

Here are the expressions worth noticing in that exchange.

• "kick off": to start a meeting or a project. More natural than "Let's start."
• "capacity check": the step where you confirm the team's availability, personal schedules and on-call included.
• "Does that feel reasonable?": a polite way to seek the team's agreement. More professional than "Is that okay?"
• "factor those in": to include existing items in the calculation. Used for carryover stories and other variables.

Discussing Story Point Estimates

Story point estimation is the stretch of the meeting with the most live debate. You have to state the reasoning behind your own number clearly, and lead a constructive discussion when it differs from someone else's.

Running Planning Poker

[Running planning poker]

"Let's estimate this story using planning poker.
 Everyone, show your cards on three — one, two, three."
(Counting down to the reveal keeps every estimate independent.)

"We have a spread — I see a 3, two 5s, and an 8.
 Let's hear from the low and high estimators."
("Spread" is the neutral word for disagreement in the cards.)

"Can you walk us through your reasoning for the 8?"
("Walk us through your reasoning" asks for the why, not a defense.)

Explaining a Difference in Estimates

[Explaining your estimate]

"I'd estimate this at 5 points — there's moderate complexity
in the integration layer, and we've done similar work before."
(Gives a number plus the two reasons behind it.)

"I went with 8 because this touches three different services,
and the testing effort alone could take a full day."
("I went with 8 because" is the standard opener for a justification.)

"My concern is the unknown unknowns in the legacy code path.
 That's why I estimated higher."
("Unknown unknowns" is the phrase for risk you cannot size yet.)

Proposing a Story Split

[Proposing a story split]

"This story feels too large. Can we split it into smaller,
independently deliverable pieces?"
("This story feels too large" opens the split conversation gently.)

"I'd suggest splitting this into the API layer and the
frontend implementation as two separate stories."
(Proposes the exact seam to split along.)

"If we can't estimate it confidently, maybe we need a
spike first to reduce the uncertainty."
(A spike is the answer when the estimate itself is the problem.)

Real Dialogue 2: A Planning Poker Debate

[Setting: the team estimates a payment system refactoring story]

Alex:
  "Next story — refactor the payment processing module
   to support the new payment gateway. Cards up —
   one, two, three."

(Cards revealed: You=5, Sarah=8, Mike=5, Alex=3)

Alex:
  "Interesting spread. I went with 3 because we already
   have the adapter pattern in place. Sarah, why 8?"

Sarah:
  "The adapter pattern helps, but we also need to handle
   three new error codes and update the retry logic.
   Plus, the current test coverage is only at 40 percent,
   so we'll need significant testing effort."

You:
  "That's a fair point about the test coverage. I hadn't
   considered the retry logic changes. I'd revise my
   estimate up to an 8 as well."

Mike:
  "Same here. With the testing effort, 8 makes more sense."

Alex:
  "I'm convinced. Let's go with 8. Sarah, good catch
   on the test coverage gap."

Here are the expressions to take from this exchange.

• "Cards up": the compact instruction to reveal cards in planning poker.
• "Interesting spread": a neutral way to note that the estimates came out far apart.
• "That's a fair point": acknowledges the other person's argument. A natural way to signal you are changing your mind.
• "I'd revise my estimate up to...": the professional way to change an estimate.
• "Good catch": thanks a colleague for spotting what you missed.

Communicating Technical Debt

Conveying technical debt effectively, to the team and to stakeholders, is a core senior-engineer skill. Not "the code is bad," but an explanation built around the impact on the business.

Reporting Technical Debt

[Reporting technical debt]

"I'd like to flag a growing area of technical debt
in our authentication module."
("Flag a growing area of technical debt" raises it without alarm.)

"This technical debt is increasing our cycle time by
roughly 20 percent for any story that touches the
user service."
(Turns the debt into a cycle-time number.)

"We've been working around this issue for three sprints now,
and the workarounds are becoming increasingly fragile."
("The workarounds are becoming fragile" is the urgency signal.)

Conversation Patterns With the Product Owner

Explaining the debt from the business point of view is the key.

[Discussing technical debt with the PO]

"If we don't address this now, every feature that touches
payments will take an extra two to three days."
(Prices the inaction in days, which the PO can actually weigh.)

"I'm not proposing we stop everything — I'm suggesting
we allocate 20 percent of our capacity to pay down
this debt over the next two sprints."
(Rules out the extreme option first, then names a bounded ask.)

"The risk of not addressing this is that our deployment
frequency will continue to drop, and incident response
time will increase."
(Frames it as risk to delivery metrics rather than as code quality.)

Real Dialogue 3: Explaining Technical Debt to the PO

[Setting: you explain to Jessica, the PO, why the debt needs paying down]

You:
  "Jessica, I'd like to bring up a technical debt item
   during this planning session. Our database query layer
   in the order service has accumulated significant debt
   over the past six months."

Jessica (PO):
  "Can you help me understand the impact? How does this
   affect our delivery timeline?"

You:
  "Sure. Right now, any story that involves order-related
   queries takes about 30 percent longer than it should.
   Last sprint alone, we spent an extra three days
   on workarounds."

Jessica:
  "That's substantial. What would addressing this look like?"

You:
  "I'd propose a two-sprint approach. We dedicate about
   15 percent of our capacity each sprint to incrementally
   refactor the query layer. We wouldn't need a full
   feature freeze — we can do this alongside regular work."

Jessica:
  "And what's the expected outcome?"

You:
  "After the refactoring, we expect order-related stories
   to return to their normal velocity. We'd also reduce
   our P2 incident rate in that area, which has been
   trending upward."

Jessica:
  "That makes sense. Let's include it in the sprint backlog.
   Can you create the stories so we can track progress?"

You:
  "Absolutely. I'll break it down into four incremental
   stories and have them ready by end of day."

Here are the expressions worth analyzing.

• "bring up": to raise a topic in a meeting. More natural than "I want to talk about."
• "accumulated significant debt": the phrasing for debt that has built up. "Accumulated" is the key word.
• "a two-sprint approach": the pattern of attaching a concrete timeline to a proposal.
• "feature freeze": halting new feature work. Saying you do not need one puts the PO at ease.
• "trending upward": says a metric is on an upward trend. Central to data-driven communication.

Backlog Refinement Expressions

Backlog refinement is where you confirm a story is ready before it enters a sprint: does it meet the Definition of Ready, and are the acceptance criteria clear?

Checking the Definition of Ready

[Checking Definition of Ready]

"Does this story meet our Definition of Ready?"
(The single question that gates a story into the sprint.)

"We're missing the acceptance criteria for the error
handling scenarios."
(Names the exact gap rather than saying "not ready.")

"I don't think this is ready for estimation yet.
 We need design mockups for the new UI flow."
(Says what is missing and what would fix it.)

Discussing Acceptance Criteria

[Discussing acceptance criteria]

"Can we clarify the acceptance criteria for this story?
 I want to make sure we're aligned on what 'done' looks like."
("What 'done' looks like" is the plainest way to ask for criteria.)

"Should the acceptance criteria include performance
requirements? For example, response time under 200
milliseconds?"
(Pushes for a number in the criteria, not just a behavior.)

"I'd suggest we add a criterion for backward compatibility
with the existing API consumers."
(Adds the compatibility criterion explicitly.)

Identifying Dependencies

[Identifying dependencies]

"This story has a dependency on the platform team's
API changes. Have those been deployed yet?"
(Names the dependency and asks its status in the same breath.)

"We're blocked on this until the design team finalizes
the component library update."
("We're blocked on this until" states the exact unblocking event.)

"I'd recommend we identify all cross-team dependencies
upfront to avoid surprises mid-sprint."
(Front-loads dependency discovery to avoid mid-sprint surprises.)

Real Dialogue 4: Backlog Refinement

[Setting: the team refines candidate stories for the next sprint]

Alex:
  "Let's look at the next story — implement real-time
   notifications for order status updates."

You:
  "Before we estimate, I want to flag a couple of things.
   First, the acceptance criteria don't specify which
   notification channels we need to support. Is it
   just in-app, or do we also need push and email?"

Jessica (PO):
  "Good question. For the first iteration, let's scope
   it to in-app notifications only. We can handle push
   and email as follow-up stories."

You:
  "That helps scope it down. Second, this has a dependency
   on the notification service that the platform team is
   building. Last I checked, it was still in progress."

Sarah:
  "I spoke with the platform team yesterday. They said
   the notification service should be ready by midweek.
   But I'd suggest we plan a fallback in case it's delayed."

Alex:
  "Agreed. Let's add 'notification service API available'
   as a precondition in the story, and have a backup plan
   to use the existing email service as a temporary bridge."

You:
  "Sounds good. With the scope limited to in-app only
   and assuming the API is available, I'd estimate this
   at 5 points."

Here is the summary of the key expressions.

• "flag a couple of things": signals you are about to raise a few cautions or concerns.
• "scope it to...": narrows the scope to a specific area.
• "plan a fallback": to prepare a backup. Common in risk discussions.
• "precondition": a condition that must hold before the story can start.
• "temporary bridge": a stopgap connection. More structural than a plain workaround.

Disagreeing Professionally

Disagreeing with a colleague in an estimation meeting is natural. What matters is putting the objection constructively and politely.

Five Polite Ways to Disagree

Patterns for Proposing an Alternative

[Proposing an alternative]

"Instead of tackling this as one large story, what if
we broke it into two smaller ones?"
("What if we broke it into two" proposes without dictating.)

"What if we timeboxed a spike for half a day to validate
our assumptions before committing to a full estimate?"
(A timeboxed spike is the answer to a contested estimate.)

"I'd like to propose an alternative approach — we could
use the existing middleware instead of building from scratch."
("I'd like to propose an alternative approach" is the neutral opener.)

Expressions for Reaching Consensus

[Reaching consensus]

"It sounds like we're converging on 8 points. Does anyone
still have reservations?"
("Does anyone still have reservations?" is the last call.)

"Let's try a fist-of-five on this estimate.
 Five means fully confident, one means major concerns."
(Fist of five turns vague agreement into a number.)

"Can we agree to go with 5 points for now and revisit
if we discover additional complexity during implementation?"
(Commits provisionally, with a named trigger for revisiting.)

Notes for Non-Native Speakers

Agile vocabulary holds several word pairs that trip up non-native speakers. Understanding the fine distinctions makes your communication in the meeting far more precise.

Commitment vs Forecast

Modern Scrum recommends using the word forecast for the sprint goal. "We forecasted 40 points based on our velocity" is more appropriate than "We committed to 40 points."

Output vs Outcome

Complex vs Complicated

The Strength of Must / Should / Could

When you discuss the priority of a requirement, understanding the strength of the MoSCoW words matters.

Common Abbreviations and Idioms

Here are the abbreviations and idioms that come up most in sprint planning. They show up in Slack and Jira comments too, so they are worth learning.

Closing the Meeting

Wrapping Up the Action Items

[Wrapping up action items]

"Let me summarize the action items before we wrap up."
(The standard line before you read the action items back.)

"You, Sarah — you'll pair on the database migration story.
 Mike — you'll reach out to the platform team about
 the API dependency."
(Names an owner for each item, one at a time.)

"Does anyone need any clarification on their tasks
for this sprint?"
(The final check that nobody leaves the room unclear.)

Confirming Next Steps and Closing

[Closing the meeting]

"We've planned 37 points for this sprint, which is
within our forecasted capacity. The sprint goal is
to deliver the checkout optimization to staging."
(Restates the point total, the capacity fit, and the goal.)

"Our daily standup is at 10 AM as usual. If you hit
any blockers, please raise them there or in the
team Slack channel."
(Confirms the standup slot and where to raise blockers.)

"Great planning session, everyone. Let's have a
productive sprint."
(A short, warm close.)

Full Scenario: A Complete Sprint Planning Conversation

Below is a condensed script of a full 20-minute sprint planning meeting. Follow the real flow and watch how the key expressions get used.

Real Dialogue 5: The Full Planning Script

[Participants: Alex (Scrum Master), Jessica (PO), You, Sarah, Mike]

=== Phase 1: Opening ===

Alex:
  "Alright team, let's get started with Sprint 25 planning.
   Quick logistics — we have 60 minutes blocked for this.
   Jessica, do you want to kick us off with the sprint goal?"

Jessica:
  "Thanks, Alex. The business priority this sprint is to
   complete the new onboarding flow. We've been getting
   feedback that the current flow has a 40 percent
   drop-off rate, and this is directly impacting our
   conversion metrics."

Alex:
  "Clear goal. Let's do a capacity check. Any reduced
   availability this sprint?"

Mike:
  "I'm attending a two-day conference on Wednesday
   and Thursday, so about 60 percent capacity for me."

You:
  "Fully available. No conflicts on my end."

Sarah:
  "Same here, fully available."

Alex:
  "Got it. With Mike's reduced capacity, I'd suggest
   we target around 35 points. Our three-sprint average
   is 40, so 35 gives us a comfortable buffer."

=== Phase 2: Story Estimation ===

Jessica:
  "The first and highest-priority story is: 'As a new
   user, I can complete the signup flow in under
   two minutes.' The acceptance criteria are in the
   Jira ticket."

Alex:
  "Everyone had a chance to review this in refinement.
   Let's estimate — cards up. One, two, three."

(Cards: You=5, Sarah=5, Mike=8, Alex=5)

Alex:
  "Mostly aligned. Mike, you're at 8 — what's driving
   the higher estimate?"

Mike:
  "I think we're underestimating the email verification
   step. We need to integrate with the new email service,
   and their documentation is incomplete. I spent an hour
   looking at it yesterday and there are gaps."

You:
  "I hear your point. Have you considered that we could
   use our existing email service for now and swap it out
   later? That would remove the integration risk for
   this sprint."

Mike:
  "That could work as a short-term solution. If we go
   that route, I'd be comfortable with a 5."

Sarah:
  "I'd support that approach. We can create a follow-up
   story for the email service migration."

Alex:
  "Consensus on 5? Great, let's move on."

=== Phase 3: Technical Debt Discussion ===

You:
  "Before the next story, I'd like to bring up a tech
   debt item. The authentication middleware has been
   causing intermittent test failures for the past three
   sprints. It's costing us about half a day per sprint
   in debugging time."

Jessica:
  "How much effort would it take to fix?"

You:
  "I'd estimate it at 3 points. It's mostly about
   replacing the deprecated session handling library
   and updating the related tests."

Jessica:
  "Given that it's been a recurring time sink, I'm
   supportive of including it. Let's add it to the
   sprint backlog."

Alex:
  "Agreed. That brings us to 8 points so far with
   plenty of room."

=== Phase 4: Dependency and Risk ===

Alex:
  "Next story — implement social login with Google
   and GitHub."

Sarah:
  "I have a concern about this one. The security team
   needs to review our OAuth implementation before we
   can go live. Have they confirmed availability for
   a review this sprint?"

Alex:
  "Good catch. I'll reach out to the security team today
   to confirm. If they can't do the review this sprint,
   we might need to adjust our plan."

You:
  "Could we structure the story so that the implementation
   is one story and the security review is a separate
   blocker? That way we can proceed with the code and
   not merge until the review is complete."

Alex:
  "Smart. Let's split it that way."

=== Phase 5: Closing ===

Alex:
  "To summarize — we've planned 34 points for Sprint 25.
   The sprint goal is to deliver the new onboarding flow.
   Action items: I'll confirm the security review timeline,
   Mike will create the follow-up story for the email
   service migration, and everyone starts pulling from
   the top of the board tomorrow morning."

Jessica:
  "Thanks, team. I'm confident about this sprint goal.
   Let me know if any questions come up about the stories."

Alex:
  "Great session, everyone. Let's make it a strong sprint."

Here are the patterns most worth noticing in that full exchange.

Managing the flow of the meeting

• "Let's get started with..." — opening the meeting
• "Let's do a capacity check" — shifting to availability
• "Let's estimate — cards up" — shifting to estimation
• "Before the next story, I'd like to bring up..." — introducing a new topic
• "To summarize..." — the closing recap

Reaching consensus

• "Mostly aligned" — largely in agreement
• "Consensus on 5?" — checking for agreement
• "I'm supportive of including it" — the PO signalling agreement
• "Smart. Let's split it that way." — quick agreement with a good proposal

Managing risk

• "What's driving the higher estimate?" — asking the reason behind a high number
• "I have a concern about this one" — voicing a worry
• "If they can't do the review this sprint, we might need to adjust" — a conditional plan

References

• Sprint Planning in English - Speak Tech English
• Sprint Planning - Atlassian
• Facilitation Techniques - Scrum.org
• Story Points Estimation - Atlassian
• Technical Debt in Scrum - Scrum.org
• Backlog Refinement - Atlassian
• Tips for Non-native English Speakers - Scrum.org