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.