English Phrases for Sprint Retrospectives
The exact English phrases and vocabulary you need to contribute confidently to sprint retrospectives — including went well, improvements, and action items.
The sprint retrospective is one of the most valuable meetings in agile — and one of the most language-intensive. You need to reflect on past events, express opinions diplomatically, give and receive constructive feedback, and commit to change. All in English, live, in front of your team.
This guide gives you the phrases you need to participate confidently in every part of a retrospective.
The Classic Retrospective Format
Most retrospectives use some version of the “three columns” format:
| Column | The question | What it covers |
|---|---|---|
| What went well? | What should we continue? | Successes, smooth processes, good collaboration |
| What could be improved? | What was difficult or frustrating? | Problems, friction, missed expectations |
| Action items | What will we do differently? | Specific changes with owners and deadlines |
Some teams use variations like “Start / Stop / Continue” or “Liked / Lacked / Learned.” The vocabulary is transferable across all formats.
Phrases for “What Went Well”
“I thought our communication during the deployment went really smoothly this sprint.”
“I’d like to call out the way the team handled the production incident — everyone was responsive and the resolution was fast.”
“The pair programming sessions we tried this sprint were genuinely useful. I’d like to continue doing that.”
“The new PR template is working well — reviews are faster and more consistent.”
“I appreciated how quickly blockers were escalated this sprint. We didn’t lose much time waiting.”
Key vocabulary: call out (highlight positively), appreciate, smooth, went well, worked well, I’d like to continue.
Phrases for “What Could Be Improved”
This is the section where language matters most. You want to be honest without being accusatory.
“I felt like our sprint planning was a bit rushed this time. We committed to more points than we could realistically deliver.”
“The handover between the backend and frontend teams wasn’t as clear as it could be. There were a few misunderstandings about the API contract.”
“I struggled with the unclear acceptance criteria on a few tickets. I had to go back to the PO several times to clarify.”
“I noticed we had quite a few unplanned interruptions this sprint — support requests that weren’t in the original scope.”
“Deployment took much longer than expected, partly because we didn’t have a runbook. That slowed us down significantly.”
Use “I felt”, “I noticed”, “I struggled with” — these are personal observations, not accusations. Avoid “you always” or “the team never”.
Suggesting Improvements
“One thing that might help is setting a time limit on sprint planning — say, 2 hours maximum.”
“Could we try having a short API alignment meeting before development starts? That might prevent the integration issues we had.”
“I’d suggest adding clearer acceptance criteria to every ticket before the sprint begins. Even a simple checklist would help.”
“What if we reserved the last 30 minutes of each day for async communication catch-up? That might reduce the interruptions during focus time.”
“I think we should document the deployment steps before the next release. It would save a lot of time and reduce stress.”
Key phrases: one thing that might help, could we try, I’d suggest, what if we, I think we should.
Committing to Action Items
“I can own the runbook if we agree to add that as an action item.”
“I’ll update the PR template before the next sprint to include the sections we discussed.”
“Can we assign someone to define the acceptance criteria standard? I’m happy to do a first draft.”
“Let’s make this a team commitment for next sprint and check in at the next retro.”
“I’ll follow up on this with the PO after the meeting — can we mark it as an action item?”
Useful Retrospective Vocabulary
| Phrase | Meaning |
|---|---|
| sprint goal | The main objective agreed at the start of the sprint |
| velocity | The amount of work completed (measured in story points) |
| carry-over | Tickets not completed that move to the next sprint |
| blocker | Something preventing progress |
| retrospective action | A specific improvement agreed during the retro |
| PO / product owner | The person who defines and prioritises requirements |
| acceptance criteria | The conditions a story must meet to be “done” |
| time-box | A fixed, limited period of time for an activity |
| working agreement | Rules the team agrees to follow together |
Responding to Others’ Points
“I had a similar experience — I’d support making that an action item.”
“That’s a good point. I hadn’t thought about it from that angle.”
“I see where you’re coming from, though I’m not sure that was the main issue. What do others think?”
“Can you say more about that? I want to make sure I understand the problem before we decide on a solution.”
The retrospective is one of the few meetings where everyone’s voice matters equally. Knowing the right phrases means you can contribute meaningfully, give honest feedback without creating tension, and help your team continuously improve — in English, with confidence.
Navigating Subtle Discomfort – “Let’s Dig Deeper”
Retrospectives aren’t just about ticking boxes; they’re about honest reflection and collaborative improvement. One of the trickiest aspects for non-native English speakers is navigating potentially sensitive feedback or disagreements without causing unnecessary discomfort. The phrase “let’s dig deeper” can be incredibly useful here, but it needs to be deployed strategically. It signals a desire for clarification and understanding, moving beyond surface-level observations. Often, what sounds critical – a statement about slow build times, for example – might simply require more context. Someone saying “builds are taking too long” without elaborating could easily be interpreted as blame. “Let’s dig deeper” invites the speaker to explain the specific impact and any contributing factors they’ve observed. It shifts the focus from judgment to understanding why something is happening.
Furthermore, it’s crucial to remember that active listening isn’t just about hearing words; it’s about demonstrating you understand the underlying sentiment. Phrases like “I hear what you’re saying about…” or “Can you tell me more about…?” acknowledge the speaker’s perspective and create space for elaboration. Don’t immediately jump in with a counter-argument or attempt to fix the problem before fully grasping the issue. Resist the urge to interrupt; let the person finish their thought completely. A common pitfall is formulating your response while they are still speaking, leading to disjointed communication. Practicing phrases like “I’m just trying to understand…” can also be helpful in diffusing tension and signaling a genuine desire for clarity. Remember, the goal isn’t to win an argument; it’s to collectively improve the process.
Another subtle but important shift comes with framing suggestions constructively. Instead of saying “We should automate this,” which can sound dismissive of existing manual processes, try “I wonder if we could explore automating this step? Perhaps we could investigate the time savings and potential for reduced errors.” This approach presents an idea as a question, inviting collaboration rather than dictating a solution. Similarly, when discussing impediments, focus on describing the impact rather than assigning blame. Instead of “John always misses deadlines,” try “I’ve noticed that tasks assigned to John have frequently been delayed, which has impacted the team’s ability to meet sprint goals.” This shifts the conversation from personal criticism to a shared problem requiring a solution.
Finally, it’s vital to acknowledge your own communication style and potential areas for improvement. If you find yourself struggling to articulate your thoughts clearly in English, don’t hesitate to ask for clarification or feedback. A simple “Could you help me rephrase that?” can go a long way.
# Example: Investigating build times using `dotnet` CLI
dotnet build --verbose # Verbose output provides details about the build process