• /
  • /
Workplace English for Tech Teams

How to Lead a Retrospective in English

Author: Ksenia Izotova
Last updated: September 2026
Retrospective agenda moving from observations to one agreed team action

What does a facilitator need to do in English?

To lead a retrospective in English, explain the purpose, give people a manageable way to contribute, help the team examine specific events, and close with an agreed improvement to try. Use questions that distinguish observations from assumptions. Invite different accounts of what happened, interrupt blame when it appears, and record the next action, its owner and a review point. Clear facilitation matters more than sounding fluent throughout the meeting.

A facilitator asks, “Any problems this sprint?”

Two people say no. One says, “Communication could be better.” Nobody asks what that means. The meeting ends with an action to communicate more.

The following week, the same problem returns.

The English was understandable. The conversation never reached a specific event or a change the team could try.
The retrospective, names and exchanges below are illustrative examples. The agenda is a suggested format to adapt to your team.

Set the purpose before asking for opinions

In Scrum, the retrospective examines how the Sprint went and identifies improvements to quality and effectiveness. It can cover interactions, processes, tools and the Definition of Done. It is distinct from the Sprint Review, which examines the product outcome with stakeholders. Source: Scrum Guide, Sprint Retrospective

Open in language that makes the task concrete:
“Today we’ll look at what helped and what made work harder during the last sprint. We’ll choose an improvement we can try next sprint and agree how to review it.”

For an established team, revisit the last action first:
“We agreed to add a QA review before finalising acceptance criteria. Did we try it? What difference did it make?”

If an action was not attempted, ask what prevented it. Adding new actions without checking old ones can make the meeting feel disconnected from work.

Give people a way into the conversation

Open discussion can favour the people who formulate answers fastest. A short period of individual writing gives participants time to think and prepare their English.

“Take a few minutes to write one thing that helped and one thing that made your work harder. A short sentence is enough. Include a specific example if you can.”

Then invite clarification:
“There are several notes about late changes. Can someone describe one change and what happened afterwards?”

Do not assume silence means agreement or poor English. Someone may lack context, disagree with the question, need thinking time or feel uncomfortable speaking publicly.

An example agenda for a short retrospective

For a team choosing a 45-minute session, this is one possible allocation. It is not a Scrum requirement; adjust the duration and activities to the team’s needs.
The facilitator can protect time while keeping an unresolved concern visible:

“We have ten minutes left. Shall we use them to define the handover experiment? I’ll record the tooling issue for a separate discussion with the people who need to be there.”

Turn vague complaints into useful discussion

“Product always changes everything”

Context: A QA engineer describes acceptance criteria changing late in a sprint.

Risk: “Always” and “everything” invite an argument about exaggeration. Product may start defending the department rather than examining the change.

Facilitator: “Which change are you thinking of, and what did it affect?”

More useful contribution: “The export criteria changed on Thursday, after we wrote the tests. We had to rewrite three cases and left less time for regression.”

Then ask for the other perspective: “What prompted the change?” Late changes can have a legitimate reason. The team needs to understand the sequence before selecting a remedy.

“Nobody told us”

Context: Information was posted in a channel that some team members do not follow.

Risk: The speaker may be heard as accusing colleagues of withholding information. Others respond by proving that a message was sent.

Facilitator: “Where was the decision recorded, and where would the testing team normally look for it?”

More useful contribution: “The decision was in the product channel, but the ticket still had the old criteria. I worked from the ticket.”

This makes a possible process gap visible. Whether it is the main cause still needs discussion.

“We need better communication”

Context: The team is drafting an action after discussing unclear handovers.

Risk: Everyone can agree while imagining a different change. There is no way to tell whether the action happened.

Facilitator: “What would someone do differently in the next handover?”

More useful action: “For the next sprint, the person handing a feature to QA will add the staging link and any known limitations to the ticket. We’ll check how that worked at the next retrospective.”

Confirm that the people doing the work agree the experiment is feasible.

Handle disagreement without forcing agreement

If two people remember an event differently:
“We have two accounts of when the change became visible. What can we check in the ticket or messages?”

If someone challenges an interpretation:
“You agree that the handover was late, but disagree about what caused it. Let's separate those two points.”

If a contribution becomes personal:
“I’m going to pause there. Please describe the action and its impact. We can discuss the problem without making a judgement about someone's competence.”

If you need time to formulate your own response:
“Let me make sure I’ve understood before we move on.”

You can acknowledge the seriousness of an issue without resolving it publicly. Personal grievances or misconduct may require a separate, appropriate process. Do not promise confidentiality that the meeting setup cannot provide.

Invite quieter participants without putting them on the spot

Try:
“We’ve heard the implementation perspective. Does anyone want to add what happened during testing?”

Or:
“You can add a note first if that’s easier. We’ll leave a minute to read the board.”

If you directly invite someone, allow them to pass. A public demand to speak can make participation harder. Anonymous input can sometimes help, but do not call a tool anonymous unless its settings support that claim.

When someone searches for a word, allow them time. If they want help, offer a paraphrase and check it: “Do you mean the requirement was unclear, or that it changed?” Those are different problems.

Close with an experiment the team can review

“We’ve agreed to try the updated QA handover for one sprint. Elena will add the fields to the template; everyone handing over work will use them. At the next retrospective, we’ll check whether the staging link and known limitations were available when QA started, and what remained unclear.”

Avoid turning this into a promise that all clarification questions will disappear. The experiment should help the team learn whether the change addresses the problem.

Frequently asked questions

Do I need C1 English to facilitate a retrospective?

There is no universal CEFR threshold for facilitation. You need to understand contributions, ask follow-up questions, summarise disagreement and manage turn-taking. Prepare language for those actions and get help if the discussion exceeds what you can follow.

What should I do when nobody speaks?

Allow thinking time, narrow the question and offer written participation. "Which handover was hardest this sprint?" is easier to answer than "What should we improve?" Also consider whether previous contributions have been heard and acted on.

Should I correct people's English during the retrospective?

Prioritise understanding. Clarify wording when it changes the meaning. General language correction can interrupt a work discussion; save it for a separate learning setting if participants want it.

Can a language course make a team feel safe to speak?

Practice can help people formulate a concern and manage a discussion. Trust also depends on how colleagues and leaders respond. Language training cannot compensate for retaliation or repeated dismissal of concerns.

Rehearse the moments that are hardest to facilitate

UnifyHub's English for engineering managers and English for QA engineers programmes cover relevant team conversations. Book a team assessment to discuss the situations to prioritise. For disagreement in writing, read how to disagree in a code review.

Before your next retrospective, practise three moments: opening the meeting, asking for a concrete example and interrupting a personal criticism. Ask a colleague to give you an unexpected answer. The follow-up is usually the part worth rehearsing.
Author: Ksenia Izotova
Last updated: September 2026

Related articles