If you’ve ever sat quietly in a sprint planning meeting, nodding along while secretly unsure how to estimate a story or push back on scope — this post is for you.

Agile ceremonies like sprint planning, retrospectives, and backlog refinement are full of structured English you can learn and reuse. Once you know the patterns, speaking up becomes much easier.


Sprint Planning: Key Phrases

Sprint planning has two main jobs: deciding what to build and how to build it. Here’s the language for both.

Discussing scope and stories

  • “Can we clarify the acceptance criteria for this story?”
  • “This ticket seems to have some dependencies. Should we resolve those first?”
  • “I think this is too vague to estimate. Can we break it down further?”
  • “Who has context on this? I’d like to hear more before we commit.”

Estimation

  • “I’d give this a 5. The API integration alone is risky.”
  • “I’m voting 8 because we’ve never done this kind of migration before.”
  • “Why did you vote 13? I’m curious what you’re seeing that I’m missing.”
  • “Can we spike this first and estimate next sprint?”

Pushing back or raising concerns

  • “I’m worried we’re taking on too much. We have three carryover stories already.”
  • “I don’t feel confident we can finish this in one sprint without cutting scope.”
  • “Could we split this into two stories — one for the backend, one for the UI?”

Common Mistakes Vietnamese Speakers Make

1. Saying “I think maybe…” too often

This hedges your point so much that people stop listening. Be direct:

  • Instead of: “I think maybe this story is a bit unclear…”
  • Say: “This story needs clearer acceptance criteria before we can estimate it.”

2. Asking permission instead of making a proposal

  • Instead of: “Can I say something about this task?”
  • Say: “I’d like to flag a concern about this task.”

3. Agreeing to deadlines you can’t meet

When pressed for a deadline, it’s okay to say:

  • “I can commit to the API being done by Thursday, but the UI will need more time.”
  • “I’ll need to check with the team before I can confirm that date.”

Retrospective: The Language of Honest Feedback

Retrospectives are where teams improve. But they require a specific kind of honest, constructive English — especially when something went wrong.

The three classic prompts (and how to answer them)

What went well?

  • “The deployment was smooth this sprint. We had zero rollbacks.”
  • “Daily standups felt focused — we kept to 15 minutes every day.”
  • “Communication with the product team improved a lot.”

What didn’t go well?

  • “We underestimated the complexity of the payment integration.”
  • “We had too many context switches mid-sprint. It hurt our focus.”
  • “Some tickets were merged without proper review. We need to address that.”

What should we try next sprint?

  • “I’d like to try mob programming on complex tasks.”
  • “Can we add a ‘definition of done’ checklist to our tickets?”
  • “Let’s timebox our standup to strictly 15 minutes.”

Example Dialogue: Sprint Planning

Scrum Master: Okay, let’s look at the next story — implementing the export CSV feature. Story points?

Nam (developer): I’m voting 8. We don’t have a reusable export utility yet. We’d need to build it from scratch.

Scrum Master: Anyone vote differently?

Linh (developer): I voted 5. I was thinking we could use the existing report module as a base.

Nam: That’s a good point. But the report module doesn’t handle large datasets well. We’d need to refactor it.

Scrum Master: So there’s a risk around performance?

Nam: Yes. I’d suggest we spike the export feature first — one day to test feasibility, then re-estimate.

Scrum Master: That sounds reasonable. Let’s add a spike story.


Example Dialogue: Retrospective

Scrum Master: What didn’t go well this sprint?

Tuan (developer): Honestly, the scope kept changing mid-sprint. We finished what we planned, but two new urgent tasks came in from the business and disrupted our flow.

Scrum Master: How did that affect the team?

Tuan: It created a lot of context switching. I’d suggest we define a clearer process for handling urgent requests during a sprint — maybe a fast-track lane with the PO.

Product Owner: That’s fair. Let’s discuss how we can handle that better. Can you help draft a proposal, Tuan?

Tuan: Sure. I’ll have something ready by our next planning session.


Useful Agile Vocabulary

TermHow to use it naturally
Velocity”Our velocity last sprint was 42 points — a bit lower than usual.”
Spike”Let’s spike this first before we estimate.”
Carryover”We have two carryover stories from last sprint.”
Blocker”I have a blocker — waiting on API credentials from the third party.”
Scope creep”This is starting to feel like scope creep. Should we create a separate ticket?”
Definition of done”Is this really done? It doesn’t meet our definition of done yet.”

Quick Reference: Go-to Phrases

To clarify:

  • “Can you walk me through the acceptance criteria?”
  • “What does success look like for this story?”

To raise a concern:

  • “I want to flag a risk here.”
  • “I’m not comfortable committing to this without more clarity.”

To propose a solution:

  • “One option would be to…”
  • “What if we broke this into two separate stories?”

To ask for time:

  • “Can I get back to you on that tomorrow?”
  • “I’ll need to look at the code before I can give you an accurate estimate.”

Agile meetings have a predictable rhythm. The phrases above aren’t complicated — they just need to feel natural. Practice them before your next standup, and you’ll find it much easier to contribute confidently in English.

The goal isn’t perfect English. The goal is to be heard.

Export for reading

Comments