Sprint Retrospective English: Phrases for ScrumMasters and Engineers

Introduction

The sprint retrospective is one of the most important rituals in agile teams — it is the dedicated space where the team reflects on how they work together, not just what they built. For non-native English speakers, retrospectives can be particularly challenging because they involve expressing opinions, giving feedback to colleagues, and discussing problems with sensitivity. Learning the right vocabulary and phrases makes you a more confident and constructive participant, whether you are an engineer, ScrumMaster, or team lead.

Retrospective Formats and Their Vocabulary

Different retrospective formats use different vocabulary. Understanding the format helps you use the right language.

Start / Stop / Continue is one of the most common formats:

• “Something I’d like us to start doing is running a brief sync before deployments.”
• “I think we should stop scheduling meetings in the last hour of the day.”
• “I’d like us to continue with the pair programming sessions — they’ve been really valuable.”

The 4Ls format (Liked, Learned, Lacked, Longed for):

• “Something I liked about this sprint was how quickly we resolved the blocking dependency.”
• “One thing I learned is that our staging environment needs closer parity with production.”
• “What we lacked was clear acceptance criteria at the start of the sprint.”
• “I longed for more time to refactor the payment module — the technical debt is growing.”

The Mad / Sad / Glad format uses emotional vocabulary:

• “I was glad we shipped the feature on time despite the late requirement changes.”
• “I was mad about the repeated deployment failures on Tuesday — it cost us half a day.”
• “I felt sad that we couldn’t finish the accessibility improvements — they kept getting deprioritised.”

Facilitating Discussion

If you are running the retrospective, your job is to draw out honest contributions from everyone, not to dominate the conversation yourself.

Opening the session:

• “Let’s take a moment to reflect on the sprint before we discuss what to improve.”
• “There are no wrong answers here — the goal is to understand how we can work better together.”
• “I’d like everyone to share at least one thing, even if it feels small.”

Inviting quieter team members:

• “We haven’t heard from everyone yet — does anyone else want to add something?”
• “Is there anything from your side that we haven’t touched on?”
• “It’s fine to pass if you don’t have anything to add right now.”

Keeping focus:

• “That’s a great point — let’s park it and come back to it in the action items.”
• “I want to make sure we give this issue the attention it deserves, so let’s time-box this discussion to five minutes.”
• “Let’s focus on what we can control as a team.”

Raising Sensitive Issues Tactfully

Not all retrospective feedback is easy to give. When raising problems that involve people’s behaviour or team dynamics, phrasing matters enormously.

Using “I felt that…” for personal observations:

• “I felt that communication broke down around the handoff between front-end and back-end this sprint.”
• “I felt that our standups went over time too often, and I struggled to stay focused after.”

Framing problems as shared challenges:

• “What held us back this sprint was the unclear ownership of the database migration task.”
• “One thing that created friction was not having a clear definition of done for the new endpoint.”

Proposing improvements without blaming:

• “One thing we could try is a brief refinement session before sprint planning to reduce surprises.”
• “It might help to document our deployment steps more explicitly — I think that would have saved us time on Thursday.”

Avoid saying “You always…” or “He never…” — instead, describe the situation: “There were a few occasions this sprint where I wasn’t sure who to contact about the infrastructure issue.”

Agreeing on Action Items

Retrospectives only produce value if they lead to concrete, owned actions. The language of action items is specific.

Proposing an action:

• “Could we agree to add a brief pre-deployment checklist as an action item?”
• “I’d like to suggest we assign one person as the on-call owner per sprint — can we make that an action?”

Assigning ownership:

• “Who would like to own this? It would involve setting up the weekly architecture sync.”
• “Can we put a name next to this action before we close?”

Defining done:

• “Let’s say this action is complete when the runbook is updated and shared in the team channel.”
• “We’ll know this is resolved when we go a full sprint without a missed standup.”

Key Vocabulary

Term	Definition
retrospective	A meeting where the team reflects on the past sprint to improve future working practices
action item	A specific, agreed task with an owner and a deadline
blocker	Something that is preventing progress on a task or the sprint
improvement area	A theme or process that the team wants to work on in the next sprint
time-box	To set a fixed time limit for a discussion or activity
definition of done	An agreed checklist of criteria that must be met for a task to be considered complete
facilitation	The skill of guiding a group discussion productively without dominating it
parking lot	A metaphor for deferring a topic to be discussed later

Practice Tips

1. Write your retrospective points down before the meeting. This helps you choose precise language and avoids the pressure of finding words in real time. Even one sentence per point is enough.
2. Use “I felt that…” for anything sensitive. This simple phrase shifts the framing from accusation to observation and dramatically reduces defensiveness.
3. Practise the action item formula: verb + subject + by when. For example: “Update the deployment runbook by Friday — owner: Maria.” This pattern forces clarity and avoids vague agreements.
4. Learn the vocabulary of your team’s retrospective format. If your team uses a specific format (like 4Ls or Start/Stop/Continue), memorise the prompts so you can respond naturally and quickly.

Conclusion

Sprint retrospectives are most effective when everyone on the team feels confident enough to speak honestly. By learning the vocabulary and phrases in this guide — from “what held us back was” to “one thing we could try is” — you can contribute more meaningfully to these discussions and help your team improve sprint after sprint. The goal is not perfect English; it is honest, constructive communication that makes the team stronger.

Navigating Nuance: Phrases for Sensitive Discussions

Sprint retrospectives are inherently about surfacing challenges – technical roadblocks, process inefficiencies, or even interpersonal friction. As a ScrumMaster, your role isn’t to shut down uncomfortable conversations, but to guide them with clarity and respect. Many non-native English speakers find expressing these concerns directly challenging; the subtle nuances of tone and phrasing can easily be misinterpreted. Let’s look at some phrases that help frame difficult feedback constructively within a retrospective setting, focusing on techniques for delivering potentially sensitive information gracefully.

One key approach is to use “I” statements to own your perspective without placing blame. Instead of saying “The code review was too critical,” which can feel accusatory, try “I felt a little discouraged by the detailed feedback in the recent code review; I’m looking for ways to better understand expectations and improve my implementation.” Framing concerns around your experience helps diffuse defensiveness. Similarly, when discussing process issues – perhaps delays or unclear requirements – avoid statements like “The team is always late.” Instead, suggest: “I’ve noticed some recurring delays in our sprint planning; I’m wondering if we could explore ways to improve our estimation accuracy or refine our workflow.” This focuses on the observable behavior and invites collaborative solutions.

Another valuable technique involves acknowledging shared responsibility. Phrases like “Perhaps we can collectively look at…” or “It seems like we might have unintentionally created this bottleneck – let’s discuss how we can address it together” promote a sense of unity and avoid creating an ‘us versus them’ dynamic. When raising concerns about team dynamics, be particularly careful with your language. Instead of saying “John is always interrupting,” which is judgmental, consider “During discussions, I’ve noticed interruptions that seem to disrupt the flow; perhaps we can establish some ground rules for respectful dialogue.” This focuses on a behavior and suggests a potential solution rather than personalizing the criticism.

Finally, remember the power of active listening and validation. After someone shares their perspective, demonstrate you’ve understood by paraphrasing their point: “So, if I understand correctly, you’re saying that the lack of documentation has been hindering your ability to contribute effectively?” This shows respect for their viewpoint and opens the door for a deeper conversation. Practicing phrases like “That’s a really important point,” or “I appreciate you bringing this to our attention” can foster an environment where difficult issues are addressed openly and constructively, ultimately leading to more effective sprint retrospectives and stronger team collaboration.