A retrospective meeting is a team-focused event designed to improve work processes. To participate constructively, you need to know how to phrase feedback in a way that is both honest and helpful. This article provides actionable examples of what to say to help your team celebrate successes, identify challenges, and implement meaningful changes.
The Foundational Goal of a Retrospective
The aim of a retrospective is to enhance a team’s processes, not to assign blame. The focus is on “how” the team works together, rather than “who” caused an outcome. This approach fosters an environment of psychological safety, where team members feel comfortable sharing their thoughts without fear of judgment. This environment is a prerequisite for honest and productive conversation.
This philosophy is captured in the “Retrospective Prime Directive,” which states: “Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.” Adopting this mindset shifts the conversation from fault-finding toward a collaborative effort to learn from experience.
It encourages viewing problems as systemic, recognizing that challenges often arise from the process or tools, not individual negligence. This forward-looking approach allows a retrospective to be an agent for continuous improvement.
Examples for What Went Well
When discussing successes, moving beyond generic statements like “good job” provides more value. Specificity helps the team understand what actions should be repeated and reinforces positive collaboration.
For instance, acknowledging a teammate’s direct assistance can strengthen team bonds. You might say, “I want to thank Sarah for her help with the database migration. Her documentation was incredibly clear and saved me at least a day of effort.” Recognizing the effectiveness of a new tool is also useful: “The new automated testing script we implemented was a success. It caught several bugs that would have otherwise made it to staging.”
Appreciation for communication is also beneficial. Consider saying, “The daily check-in about the API integration was helpful. It ensured we were always on the same page and could address issues immediately.” Acknowledging a collective effort reinforces a unified team: “The way we all swarmed to fix the unexpected server outage was impressive. Everyone focused on the solution, which minimized downtime.”
Examples for What Didn’t Go Well
Articulating challenges is a difficult part of a retrospective. The goal is to raise issues in a way that promotes discussion rather than defensiveness. Framing problems around processes and using “I” statements are effective techniques that focus on personal observation and its impact.
For communication gaps, instead of saying, “The design team gave us the wrong specs,” a more constructive approach is, “I felt there was a disconnect between the design mockups and the technical requirements. I had to make some assumptions that led to rework.”
Process bottlenecks are another common source of friction. Rather than complaining that a person was a blocker, you could say, “I noticed our code review process felt slow this sprint. My pull request was waiting for three days, which impacted my next task.” This opens a conversation about the review process itself.
External factors can also be raised constructively. An effective way to phrase this is, “We ran into several unexpected dependencies with the third-party payment gateway that weren’t accounted for in our initial planning. This caused us to divert attention from our primary goals.” Using this method of feedback keeps the focus on shared challenges and collective ownership of the process.
Examples for Proposing Improvements
After identifying what went well and what didn’t, the conversation shifts toward actionable improvements. The most effective suggestions are framed as questions or collaborative proposals, which invites discussion and co-ownership from the team.
Building on an issue like a slow code review process, you could suggest a specific change. For example, “To help with the code review delays, could we experiment with a 24-hour turnaround goal for initial feedback on all pull requests?” This offers a measurable, testable solution.
If planning oversights were an issue, a proposal might sound like this: “To avoid surprises with dependencies, maybe we can dedicate a specific segment of our next sprint planning meeting to identify potential external blockers.” This suggests a direct change to an existing team ceremony.
Even proposals for new tools can be framed collaboratively. You might say, “I read about a tool that helps automate documentation. Would the team be open to me running a small demo next week to see if it could help us?” These types of suggestions turn complaints into a constructive search for solutions.
What to Avoid Saying in a Retrospective
Just as there are constructive ways to contribute, some communication patterns can undermine a retrospective’s purpose. Being mindful of what not to say is as important as knowing what to say.
One of the most damaging behaviors is making personal attacks or generalizations. Avoid statements like, “You always submit your code at the last minute.” This attacks a person’s character and habits.
Using accusatory language that assigns definitive blame is also counterproductive. Saying, “This feature failed because the requirements you wrote were bad,” places blame on one person.
Vague and overly broad complaints are not actionable. A comment such as, “This whole project was a mess,” offers no specific point for discussion or improvement. Focusing on specific, observable events and their impact on the process, rather than on people, is the most reliable way to contribute.