English for Sprint Retrospectives: Facilitation and Feedback Phrases
Speak confidently in sprint retrospectives — facilitation phrases, giving and receiving feedback, surfacing problems and agreeing actions — with diplomatic English examples.
Retrospectives are where teams talk about how they work — which means they involve honest, sometimes uncomfortable feedback. Speaking well in a retro means raising problems without blaming people, giving feedback that lands, and helping the group agree on concrete actions. This guide gives you the English to facilitate and participate in retrospectives.
The structure of a retro
Most retros follow a simple arc, and each phase has its own phrases:
- Set the stage — open and set the tone.
- Gather data — what happened (good and bad).
- Generate insights — why it happened.
- Decide actions — what we’ll change.
- Close — wrap up and commit.
Facilitation phrases
If you’re running the retro, you need phrases to open, guide, and keep things moving.
Opening:
- “Let’s start with a quick reminder: this is a blameless retro — we focus on the process, not the people.”
- “The goal today is to find one or two things we can actually change next sprint.”
- “Let’s spend five minutes gathering things, then we’ll group them.”
Guiding discussion:
- “Let’s hear from someone who hasn’t spoken yet.”
- “Can we dig into that one a bit more?”
- “Let’s park that — it’s important but it’s a separate topic.”
- “I want to make sure everyone gets a chance to add something.”
Keeping time:
- “We’ve got ten minutes left, so let’s move to actions.”
- “Let’s timebox this discussion to five minutes.”
The phrase “blameless” sets the whole tone — name it at the start.
”Went well / didn’t go well” framing
The classic retro asks three questions. Have natural phrasing for each:
What went well:
- “One thing that went really well was the pairing on the migration.”
- “I think we communicated well across teams this sprint.”
- “The deploy automation saved us a lot of time.”
What didn’t go well:
- “Something that didn’t go so well was the unclear requirements.”
- “We struggled with the flaky tests again.”
- “I felt we were stretched too thin across too many tasks.”
What we should change / try:
- “I’d suggest we agree on requirements before starting.”
- “Could we try quarantining flaky tests automatically?”
- “What if we limited work in progress next sprint?”
Notice the softeners: “I think,” “I felt,” “something that didn’t go so well.” They keep critique from sounding like an attack.
Raising problems without blaming
The golden rule of retros is criticise the process, not the person. Use these techniques:
Talk about the situation, not the individual:
Blaming: “Maria broke the build twice and didn’t tell anyone.” Blameless: “We had a couple of broken builds that went unnoticed for a while — maybe we need better build alerts.”
Use “we” instead of “you”:
Pointed: “You didn’t write tests.” Shared: “We let test coverage slip this sprint — how do we protect it?”
Use “I” statements for your own experience:
- “I felt blocked waiting on reviews.”
- “I found the requirements hard to follow.”
“I felt” describes your experience and can’t really be argued with, which keeps the conversation safe.
Giving feedback that lands
When you give feedback about something specific, be concrete and forward-looking:
- “The thing that slowed us down was X. Next time, could we Y?”
- “One observation: reviews piled up mid-sprint. Could we set a turnaround target?”
- “I’d love it if we could start standups on time — we drifted a lot.”
Pair an observation with a suggestion. Feedback without a suggested change just becomes a complaint.
Receiving feedback gracefully
Retros also test how you take feedback. Even if you disagree, acknowledge first:
- “That’s fair — I can see how that was frustrating.”
- “Good point. I hadn’t seen it from that angle.”
- “Thanks for raising that. Let’s figure out a fix together.”
Avoid getting defensive:
Defensive: “Well, that wasn’t my fault, the requirements were bad.” Open: “Yeah, the requirements were unclear — how do we get them tighter up front?”
Agreeing on actions
A retro that produces no actions was a waste of time. Drive to concrete, owned commitments:
- “So our action is: add a flaky-test quarantine. Who’ll own that?”
- “Let’s commit to one change, not five — what’s the most impactful?”
- “Can we make that a SMART action — specific and with an owner?”
- “I’ll take that one and report back next retro.”
A good action has an owner and is specific. “Communicate better” is not an action; “post a daily blocker update in the channel” is.
Before and after
Before: “This sprint was a mess. People kept breaking things and nobody knew what we were doing. We need to be more careful.”
Blaming, vague, no action.
After: “A couple of things slowed us down: we had some broken builds that went unnoticed, and the requirements were unclear at the start. One thing I’d suggest is adding a build-failure alert in our channel — I’m happy to own that. And could we agree requirements with the PM before we pull tickets in?”
Specific, blameless, with an owned action.
Common mistakes
- Naming names. Keep it about the process. “We” and “the build,” not “you.”
- Vague positives. “Good sprint” teaches nothing — say what went well and why.
- Complaints without suggestions. Pair every problem with a proposed change.
- Too many actions. One or two real changes beat ten you’ll never do.
- Actions with no owner. Unowned actions don’t happen.
- Getting defensive. Acknowledge first, even when you disagree.
Key takeaways
- Open by naming the retro blameless.
- Use “we” and “I felt” to raise problems without blaming.
- Pair every observation with a suggested change.
- Receive feedback by acknowledging first, not defending.
- End with one or two owned, specific actions — not a wishlist.
Speak this way in retros and your team will have honest, useful conversations that actually improve how you work — which is the entire point.
Navigating Nuance: Addressing Hesitations & Seeking Clarity
One of the biggest hurdles to fluent communication during a sprint retrospective isn’t necessarily complex vocabulary; it’s often the subtle art of expressing hesitation or seeking clarification without sounding critical or dismissive. Native speakers, even in informal settings like Slack channels discussing PR reviews, instinctively use phrases that acknowledge uncertainty and invite further discussion. It’s about building psychological safety – ensuring everyone feels comfortable voicing concerns, regardless of their English proficiency. A common issue is framing negative feedback directly; it can feel blunt. Instead, focusing on the impact of a problem or proposing solutions gently establishes a collaborative tone. Furthermore, recognizing that misunderstandings are inevitable—and actively addressing them—is crucial for productive retrospectives. Don’t be afraid to politely request clarification if something isn’t clear, and always prioritize understanding over immediate judgment. Remember, the goal is continuous improvement, not assigning blame. Consider the difference between saying “This code is bad” versus “I’m having trouble understanding this section of the code – could you explain your approach?” The latter invites dialogue.
Another area where nuance matters significantly is in suggesting actions during the retrospective. Simply stating “We need to fix this” lacks context and doesn’t encourage ownership. Instead, phrasing it as “It seems like prioritizing this task would address [specific problem]” demonstrates an understanding of the bigger picture and encourages others to consider the implications. Similarly, when receiving feedback – particularly if it’s delivered constructively but feels a little pointed – taking a moment to acknowledge the intention behind the comment (“I appreciate you highlighting this potential bottleneck”) can diffuse tension and open the door for clarification. It’s about actively demonstrating that you’ve heard and understood the message, even if you don’t entirely agree with it immediately. This is especially important when discussing technical debt – a phrase often intimidating to non-native speakers. Framing it as “Let’s explore how we can proactively address this technical debt to prevent future issues” sounds far more approachable than simply saying “We have too much technical debt.”
Finally, be mindful of the formality level within your team. While a sprint retrospective is generally informal, overly casual language can sometimes mask underlying concerns or create misunderstandings. Maintaining a professional tone – even when discussing challenging topics – demonstrates respect and fosters trust. Don’t underestimate the power of simple phrases like “Let’s explore…” or “What are our thoughts on…?” These invitations to participate encourage engagement and ensure everyone feels valued.
Here’s an example illustrating how these principles might be applied during a discussion about testing coverage:
# Example CLI command for checking test coverage (using pytest)
pytest -v --cov=my_project --junitxml=results.xmlThis command, often used to generate a report on test coverage, can easily become the subject of discussion if not framed carefully. Instead of simply stating “The coverage is low,” you might say: “I’ve run the coverage report using pytest and it shows a lower-than-ideal percentage. Let’s discuss how we can increase it to ensure better code reliability.” This approach combines factual information with a collaborative invitation to brainstorm solutions, demonstrating both technical understanding and a commitment to team success.