The sprint retrospective is the most important meeting in Scrum — and the most commonly run badly. A retro done well surfaces root causes, produces real commitments, and changes how the team works. A retro done badly is 45 minutes of people saying “communication could be better” and then everyone going back to doing exactly what they were doing.
For Vietnamese engineers working on international teams, retros have a specific language challenge: they require both directness and diplomacy simultaneously. You need to say something is broken without attacking the person who built it, and you need to commit to a change without making promises you can’t keep.
Here’s the English for running retros that work.
The Three Sections and Their Language
Most retrospective formats use three columns: What went well, What didn’t go well (or “what could be improved”), and Action items. Each section has its own language register.
What Went Well
This section matters more than teams think. Specific positive observations tell the team what to repeat. Generic ones (“good teamwork!”) are noise.
Generic (useless):
“The team worked well together.”
Specific (useful):
“The daily sync at 9am helped us catch the API integration issue two days earlier than we would have otherwise. That’s worth keeping.”
“Minh’s early warning on the third-party dependency being unstable gave us time to add the fallback. Good call.”
Naming specific people and specific actions — not just vague positive feelings — is what makes positive retro observations actionable.
What Didn’t Go Well
This is where language matters most. The goal is to describe problems in a way that invites problem-solving, not blame. The key technique: talk about systems and processes, not people.
Blame-forward (creates defensiveness):
“The QC team missed the regression.”
System-forward (invites problem-solving):
“We didn’t catch the regression until the demo. Our test coverage didn’t include that flow, and we didn’t have a pre-demo smoke test checklist. Those are the two gaps.”
The second version says the same thing — the regression was missed — but frames it as a process gap rather than a personal failure. That’s the frame that leads to action items that get implemented.
Other system-forward framings:
- “Our definition of done didn’t include [X], which is why it slipped through.”
- “We didn’t have a clear owner for [X], so it fell through the cracks.”
- “The requirement changed in week 2 but we didn’t update the test cases to match.”
Action Items
The most common retro failure is action items that are too vague to implement. “Improve communication” is not an action item. “Add a 10-minute async standup update in Slack by 9am every morning, owned by the current sprint lead” is an action item.
Good action item formula:
- What — the specific change
- Who — the named owner
- By when — a specific date or sprint
- How we’ll know it worked — the success measure
“Action: Add a pre-demo smoke test checklist to our Definition of Done. Owner: Lan. Done by: before next sprint planning. We’ll know it worked when we run it before the next demo without incident.”
Facilitating a Retro as Tech Lead
If you’re facilitating, your job is to keep the conversation moving and prevent two failure modes: the session becoming a blame session, or the session staying too surface-level to produce real action items.
Opening the retro:
“We have 45 minutes. I want us to spend 15 on what went well, 20 on what we want to improve, and 10 on actions. Let’s make sure every action item has a named owner before we finish.”
When someone raises a vague problem:
“Can you give me a specific example from this sprint? What actually happened?”
When discussion gets circular:
“I’m hearing the same theme come up a few different ways — it sounds like the core issue is [X]. Is that a fair summary?”
When someone is implicitly blaming a person:
“Let’s focus on what we could change about the process rather than individual decisions. What would have needed to be different for this to go better?”
When the group agrees on a vague action item:
“I want to make sure this action is specific enough to implement. Who owns it, and what does ‘done’ look like?”
Closing the retro:
“Let me read back the action items. [Read them.] Does everyone agree these are realistic for next sprint? Any concerns?”
Participating in a Retro (When You’re Not Facilitating)
If you’re a team member, not the facilitator, your contribution to a good retro is specific observations and honest ownership.
Raising a problem:
“Something I want to flag: we had three scope changes in the last two weeks, and each one came in informally through Slack. By the time it reached the sprint backlog, the original estimate was off. I think we need a clearer process for handling mid-sprint changes.”
Taking ownership of a failure:
“The deployment issue on Thursday — that was on me. I merged before the pipeline finished because I was in a hurry. I’ll add that as a personal rule: never merge without a green build. If others want to add it to our team agreement, I’d support that.”
Taking ownership cleanly — naming what you did wrong, explaining why, and committing to what you’ll change — builds enormous trust in a team. In English-speaking team culture, this is not seen as weakness; it’s seen as maturity and reliability.
Supporting a difficult observation:
“I want to echo what Minh raised about the requirements clarity. From the QC side, we saw the same problem — the acceptance criteria for story 47 was ambiguous enough that I had to guess what ‘success’ looked like. That made writing test cases really hard.”
Offering a concrete action:
“Could we add a Definition of Ready that requires acceptance criteria to be in Given-When-Then format before a story can be sprint-ready? That would give QC a clear test anchor.”
🗣️ Key Phrases to Say Out Loud
-
“Our DEFINITION of DONE didn’t INclude [X]” /aʊər ˌdɛfɪˈnɪʃən əv dʌn dɪdnt ɪnˈkluːd/ — System-forward framing for a missed item; shifts from blame to process
-
“Can you GIVE me a SPEcific exAMPle from THIS sprint?” /kæn juː ɡɪv miː ə spəˈsɪfɪk ɪɡˈzɑːmpəl/ — Facilitator move to deepen a vague observation
-
“WHO OWNS it, and WHAT does DONE LOOK like?” /huː əʊnz ɪt ænd wɒt dʌz dʌn lʊk laɪk/ — Close every action item with this; prevents vague commitments
-
“That was ON me — I’ll [specific change]” /ðæt wɒz ɒn miː/ — Clean ownership language; builds trust
-
“I want to ECHO what [name] RAIsed” /aɪ wɒnt tə ˈɛkəʊ wɒt reɪzd/ — Supporting a colleague’s point; shows you’re listening
-
“Let’s FOCUS on what we could CHANGE about the PROcess” /lɛts ˈfəʊkəs ɒn wɒt wiː kʊd tʃeɪndʒ/ — Facilitator redirect when blame surfaces
-
“Is THAT a FAIR sumMARy?” /ɪz ðæt ə fɛər ˈsʌməri/ — Check alignment before moving to action items
📚 Vocabulary
1. Retrospective /ˌrɛtrəˈspɛktɪv/ (noun)
- Meaning: An Agile ceremony held at the end of a sprint to review what happened and plan improvements
- Example: “Our retros used to be 10 minutes of complaints. Now they take 45 minutes and actually produce changes.”
2. Definition of Done (noun phrase, Agile)
- Meaning: A shared checklist that defines when a story or task is truly complete
- Example: “If it’s not in the Definition of Done, it’s not a commitment — it’s optional.”
3. Definition of Ready (noun phrase, Agile)
- Meaning: The criteria a story must meet before it can be brought into a sprint
- Example: “The story didn’t have acceptance criteria, so it violated our Definition of Ready.”
4. Action item /ˈækʃən ˌaɪtəm/ (noun)
- Meaning: A specific task with an owner and deadline that comes out of a meeting
- Example: “Every action item from the retro needs a named owner — otherwise nothing gets done.”
5. Slip through the cracks (idiom)
- Meaning: To be missed or overlooked, usually due to unclear ownership or process gaps
- Example: “The API documentation fell through the cracks because no one was clearly responsible for it.”
6. Own /əʊn/ (verb, in this context)
- Meaning: To take responsibility for something — a task, a failure, or a decision
- Example: “I own the deployment error on Thursday — I merged without waiting for the pipeline.”
7. Anchor /ˈæŋkər/ (noun, figurative)
- Meaning: A specific reference point that grounds a discussion or standard
- Example: “Given-When-Then format gives QC a test anchor — something concrete to write tests against.”
🎯 Practice Now
Exercise 1: Reframe Blame-Forward Statements
Convert these blame-forward statements into system-forward framings. Say your rewrites aloud.
- “The backend team didn’t update the API documentation.”
- “QC approved the build even though there were known issues.”
- “The product owner kept changing the requirements.”
- “The developer deployed on Friday afternoon.”
Sample rewrites:
- → “API documentation wasn’t updated when the endpoint changed — we don’t have a clear process for who keeps that current when implementations change.”
- → “We don’t have a formal policy for approving builds with known issues. QC made a judgment call without clear criteria.”
- → “We had three scope changes mid-sprint. We don’t have a clear process for evaluating and accepting mid-sprint changes.”
- → “We don’t have a policy on deployment timing. The team doesn’t have shared agreement on when deployments are appropriate.”
Exercise 2: Make the Action Item Specific
Take this vague action item and make it specific using the what/who/when/success formula. Say your version aloud.
“We should improve how we handle mid-sprint requirement changes.”
Your version should include:
- What specifically will change (e.g., a new process, a new channel, a new meeting)
- Who owns implementing it
- When it will be in place (before next sprint planning? end of next sprint?)
- How you’ll know it’s working
Exercise 3: Full Retro Moment Role-Play
Read this dialogue aloud, playing both parts. Aim for natural pace:
Facilitator: “Alright — what didn’t go well this sprint?”
Team member: “The production incident on Wednesday took six hours to resolve. I think we need better runbooks.”
Facilitator: “Good flag. Can you say more specifically what was missing? Was it that the runbook didn’t exist, or that it existed but was hard to find, or that the steps were wrong?”
Team member: “Honestly, a bit of everything. The runbook was outdated — it still referenced the old database setup. When we were in incident mode, we wasted two hours following steps that didn’t apply anymore.”
Facilitator: “So the process gap is: we don’t have a review step to keep runbooks updated when infrastructure changes. Does anyone want to own an action item on that?”
Team member: “I’ll own it — I’ll audit the three most critical runbooks by next Friday and flag which ones need updates.”
Facilitator: “Great. To confirm: by next Friday, you’ll audit the top three runbooks and flag outdated ones. We’ll know it worked when those runbooks are current before our next incident. Does that capture it?”
Retros are the mechanism by which teams get better. A team that runs them well has a compounding advantage — each sprint, they become slightly better at delivering. A team that runs them badly just repeats the same problems with different names.
The language is straightforward. The discipline to use it — to be specific, to own failures, to close on real action items — is what makes the difference.