Every two weeks, the moment arrives. The sprint ends, and suddenly you have 15–30 minutes to stand in front of product managers, executives, and clients to show what your team built. For many Vietnamese developers and tech leads, this is one of the most stressful English situations at work — not because of the code, but because of the language.
I’ve been running sprint demos in English for over a decade. Here’s what actually works.
Why Sprint Demos Are Hard (Even When Your Code Is Great)
The technical part is the easiest. You know what you built. The hard part is narrating it in real time, handling unexpected questions, and managing the room — all in a second language.
The most common mistakes I see:
- Reading bullet points instead of telling a story
- Using technical jargon when stakeholders need plain language
- Freezing when someone asks an off-script question
- Saying “sorry” or “maybe” too much, which undermines confidence
The fix isn’t grammar. It’s having the right phrases memorized so your brain can focus on the content, not the language.
Opening the Demo
How you start sets the tone. A strong opener tells people what they’re going to see and why it matters.
Weak opener:
“Okay so… this sprint we worked on the checkout flow. I will show you.”
Strong opener:
“In this sprint, we focused on reducing checkout abandonment. I’ll walk you through three changes we shipped, and by the end, you’ll see how they work together to solve the problem we identified last month.”
Notice the difference: the strong opener explains the why, previews the structure, and connects to a previous conversation.
Opening templates:
“This demo covers [X], [Y], and [Z]. We’ll start with [X] because it has the most impact.”
“Before I show the feature, let me quickly recap the problem we were solving — because the design decisions will make more sense with that context.”
“We have about [N] minutes. I’ll focus on what’s changed since the last demo and save time for your questions.”
Narrating the Feature
As you click through the UI or show code, your narration needs to bridge what people see with what they should understand.
Use the pattern: Action → Result → Significance
“When the user clicks here [action], the system validates in real time without a page reload [result]. This means they see errors immediately instead of after submitting — which was our #1 complaint in user feedback [significance].”
This is the difference between a demo and a tour. A tour shows features. A demo explains value.
Useful narration phrases:
“Notice that… / What’s important here is…”
“This might look simple, but under the hood it…”
“Let me show you the edge case we handled, because it caused problems before.”
“I’ll skip the admin view for now and focus on the user-facing change.”
Handling Questions Mid-Demo
Questions are good — they mean people are engaged. But they can derail your flow if you’re not prepared.
For questions you can answer quickly:
“Great question — actually, let me show you that right now, it’s in the next screen.”
“Yes, we did consider that. What we found was…”
For questions that need more time:
“I want to give that the right answer — can I come back to it at the end so I don’t lose our thread?”
“That’s a good point. I don’t have the exact number in front of me, but I’ll follow up in Slack after this.”
For out-of-scope questions:
“That’s actually on the roadmap for next sprint — I’ll flag it so we can discuss after.”
Never say “I don’t know” and stop. Always add what you’ll do about not knowing.
Presenting Technical Issues or Incomplete Work
Sometimes the sprint doesn’t go perfectly. Being honest builds more trust than hiding problems.
“I want to be upfront — we hit a blocker with [X] toward the end of the sprint. Here’s what we completed, and here’s our plan to finish it by [date].”
“This feature is 80% done. The core flow works, but we still have [Y] to polish. I wanted to show you the progress because the main logic is in and working.”
“We made a deliberate decision to defer [Z] so we could focus on [W]. Here’s the tradeoff we saw.”
Stakeholders respect honest communication. They don’t respect discovering problems after the fact.
Closing Strong
Many demos just… trail off. “Okay, that’s it. Any questions?”
A strong close summarizes, re-states value, and opens the floor with confidence.
“So to wrap up — this sprint we shipped [X], [Y], and [Z]. Together, these address [the original goal]. Happy to take questions, or if you want to dive deeper into any part of this.”
“That’s everything from the dev side. I’ll hand it back to [PM’s name] for the product perspective.”
“One thing I’d love your input on before we close: we have a design decision coming up about [X]. Your perspective would help us move faster.”
🗣️ Key Phrases to Say Out Loud
Practice these until they feel natural. Say them aloud — speaking is a muscle.
-
“I’ll walk you through…” /aɪl wɔːk juː θruː/ — much better than “I will show you”
-
“Notice that…” /ˈnoʊtɪs ðæt/ — directs attention without sounding bossy
-
“What’s important here is…” /wɒts ɪmˈpɔːtənt hɪər ɪz/ — signals the key insight
-
“Can I come back to that?” /kæn aɪ kʌm bæk tə ðæt/ — buys time gracefully
-
“I want to be upfront…” /aɪ wɒnt tə biː ʌpˈfrʌnt/ — signals honest communication
-
“Happy to take questions” /ˈhæpi tə teɪk ˈkwestʃənz/ — warmer than “Any questions?”
-
“To wrap up…” /tə ræp ʌp/ — signals the closing without abruptly stopping
📚 Vocabulary
1. Stakeholder /ˈsteɪkhoʊldər/
- Meaning: Anyone with interest in the project’s outcome (clients, managers, executives)
- Example: “I’ll skip the technical details — this stakeholder group doesn’t need them.”
2. Abandonment /əˈbændənmənt/
- Meaning: When users leave a process before completing it (checkout abandonment, cart abandonment)
- Example: “We reduced checkout abandonment by 15% after this sprint.”
3. Defer /dɪˈfɜːr/
- Meaning: To intentionally delay something to a later time
- Example: “We deferred the reporting feature to next sprint to stay focused.”
4. Edge case /ɛdʒ keɪs/
- Meaning: An unusual situation that happens rarely but must be handled
- Example: “Let me show you the edge case — what happens when the user has no payment method saved.”
5. Tradeoff /ˈtreɪdɔːf/
- Meaning: Giving up one thing to gain another
- Example: “The tradeoff was speed vs. flexibility — we chose speed for this release.”
6. Upfront /ˌʌpˈfrʌnt/
- Meaning: Honest and direct, saying something at the beginning
- Example: “I want to be upfront that we didn’t finish this feature completely.”
7. Deliberate /dɪˈlɪbərɪt/
- Meaning: Done on purpose, not by accident
- Example: “This was a deliberate decision — we discussed it with the team.”
🎯 Practice Now
Exercise 1: Narrate your last shipped feature
Pick one feature you shipped recently. Using the Action → Result → Significance pattern, say it aloud in 3 sentences:
- “When [user does X]…”
- “…the system [does Y]…”
- “…which means [business value Z]…”
Time yourself. Aim for under 45 seconds.
Exercise 2: Respond to a tough question
Have a colleague (or record yourself) ask these questions mid-demo. Practice responding without freezing:
- “Why did this take so long?”
- “Can we change this design?”
- “What’s the performance impact?”
- “Is this feature in the mobile app too?”
Exercise 3: Record your opener
Write a 3-sentence demo opener for your next sprint. Record yourself saying it. Listen back — does it sound confident? Adjust the pace: most non-native speakers go too fast when nervous.
⏱️ 5-Minute Drill
Read this script aloud 3 times. Focus on pausing at the commas and periods — don’t rush.
“Good afternoon, everyone. This sprint, we focused on one thing: making the onboarding flow faster for new users.
I’ll show you three changes we made, and explain why each one matters.
[Pause — click to next slide]
The first change is on the registration screen. Notice that we removed the phone number field. This might seem small, but in our data, 22% of users abandoned sign-up at that step. By removing optional friction, we expect to see a significant improvement.
[Pause]
The second change is email verification. Instead of sending a code, we now send a magic link. When the user clicks it — like this — they’re instantly logged in. No typing required.
[Pause]
And finally, the welcome screen. We added a 30-second product tour. Early user testing showed this reduced first-day support tickets by 40%.
That’s the sprint. Three changes, all focused on reducing friction in the first five minutes of the user journey.
Happy to take questions, or dive deeper into any of these.”
Great demos are practiced, not improvised. The next time you’re in the room, your language should be the least thing you’re thinking about — which means putting in the time now, before the demo.
Run it with your team before the real thing. Record yourself at least once. And remember: stakeholders don’t want perfection — they want to understand what you built and trust that you know what you’re doing. Clear English gets you there.