SAFe Knowledge Base » Iteration Retrospective
Iteration Retrospective
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
—Agile Manifesto
Summary
Agile Teams applying SAFe Scrum hold a retrospective at the end of each iteration. Each retrospective seeks to uncover what’s working well, what’s not, and what the team can do better in the next iteration. Agile Teams applying SAFe Team Kanban hold retrospectives as needed, with a recommendation to match the same per iteration cadence. This aligns improvements and actions across an ART.
Note: For more on Agile Team events, please see the Framework articles in the series: Iteration Planning, Iteration Review, Team Sync, Team Backlog Refinement, and Iteration Retrospective. Each event can be utilized for Agile Teams that use SAFe Scrum or SAFe Team Kanban.
What is an Iteration Retrospective?
The Iteration Retrospective is a regular event held at the end of each iteration during which Agile Teams review their results to identify improvements for future work. The retrospective provides a dedicated time for the team to reflect on the recently completed iteration and derive new ideas to enhance both the product increment and their internal processes. By evaluating their current practices and behaviors, teams can implement continuous, relentless improvement to become more high-performing over time. It helps ensure that every iteration yields improvements.
What is the purpose of the Iteration Retrospective?
The purpose of the Iteration Retrospective is for the team to reflect on their completed work and the methods used to achieve it. This reflection allows the team to identify potential improvements for future iterations. It’s important to note that considering future changes requires a different mindset than evaluating past actions. Therefore, the Team Retrospective is a distinct event, separate from the Team Review.
Technological revolutions demand that organizations continuously strive to keep up; otherwise, they risk falling behind and being outperformed by competitors. For a business to thrive, its teams must consistently improve. While the goal is to create teams that are both effective and efficient, it is also crucial to regularly adjust team processes to align with changes in the business environment and technological landscape in which the organization operates.
How does the Iteration Retrospective connect with the SAFe Principles?
SAFe Principle #5: Base milestones on objective evaluation of working systems – The Agile Team applies this principle to their process, ensuring all improvements are guided by facts and empirical evidence. This objective measurement helps the team focus on solving true root causes and avoid pursuing improvements based only on opinion or conjecture. They assess whether the process improvements were successful and identify areas for improvement in the coming iterations.
SAFe Principle #9: Decentralize decision-making – The people doing the work are best qualified to decide on how to improve the process. The Retrospective empowers the Agile Team to own and rapidly decide on necessary changes to their local system of work, ensuring continuous self-improvement without external bottlenecks.
Read more about SAFe Principle #5 and SAFe Principle #9:
What is the outcome of the Iteration Retrospective?
An understanding of how both the interactions and processes of the Agile Team can be improved in the future, and a plan for achieving those improvements.
What are the inputs and outputs?
Inputs to the Iteration Retrospective include:
- Iteration Goals committed to by the Agile Team in Iteration Planning.
- Metrics the Agile Team uses to understand the performance of both the system being developed and the system of people and processes that develop it.
- An understanding of what has happened throughout the Iteration.
- Any already identified improvement stories from other events, and the actions taken since the last retrospective.
A successful Iteration Retrospective event delivers the following outputs:
- Stories for improvement, to be added to the Team Backlog for prioritization in upcoming Iteration Planning Events. The stories could be about product or self-improvement in Agile Team processes, tooling, interactions, or other areas identified.
- Simple, quick improvements that do not require a story can be agreed upon and added to a list to check back in on after the coming iteration.
- Any challenges beyond the Agile Team’s ability to solve locally. Immediate challenges should be raised at one of the ART Sync events, if not sooner. Systemic challenges can be addressed through the ART’s Inspect & Adapt event at the end of the Planning Interval.
How does the Agile Team prepare for the Iteration Retrospective?
To prepare for an Iteration Retrospective, an Agile Team and the Scrum Master/Team Coach can take several actionable steps grounded in objective data and facilitation best practices:
- Gather Performance and Quality Metrics: Teams should track and compile their performance and quality metrics to fuel the retrospective discussion. Relying on objective data and complex system telemetry rather than limited anecdotal evidence ensures the team can drive fact-based, predictive improvements.
- Leverage AI for Insights: The Scrum Master/Team Coach can utilize AI as a thought partner to analyze the team’s flow data. By using AI to identify and predict potential bottlenecks or delays and suggest improvements beforehand, the team is set up for a much more effective and targeted retrospective.
- Utilize the Facilitation Guide: The Scrum Master/Team Coach should consult the SAFe “Facilitators Guide – Iteration Retrospective”. This resource includes a preparation checklist, helpful tips, and strategies to overcome common challenges, ensuring the event is highly impactful. It can be downloaded at the end of this article.
- Adopt a Continuous Improvement Mindset: Team members should come prepared to reflect on the results of the most recent iteration and to evaluate their own processes, practices, and behaviors critically.
By analyzing real data and preparing structured facilitation, the team can use the retrospective to derive actionable, high-value improvements for future work.
How to run the Iteration Retrospective?
The Iteration Retrospective is the final event of an iteration, where the entire Agile Team gathers to reflect on their recent results and derive new ideas to improve both their product increment and internal processes.
Attendees of the Iteration Retrospective event include:
- The Product Owner (PO)
- Scrum Master/Team Coach
- All other members of the Agile Team.
- Other stakeholders may attend the iteration retrospective, including representatives from other Agile Teams or ARTs if the Agile Team feels it would be useful.
Event Setup and Quantitative Review: The Scrum Master/Team Coach facilitates the event by outlining the goals, agenda, and chosen format for the session. Next, the team reviews their agreed-upon performance and quality metrics. Grounding the retrospective in objective data helps the team identify systemic patterns and determine if specific areas require further investigation or targeted analysis.
Gathering Qualitative Feedback: Following the metrics review, the team collects qualitative feedback. Members capture their thoughts using a physical flip chart or a designated digital tool. Facilitators often use popular formats to spark this discussion, such as:
- Individual: Writing sticky notes independently before grouping similar themes.
- Appreciation: Recognizing team members who were especially helpful during the iteration.
- Conceptual: Describing the entire iteration in a single word.
- Rating: Scoring the iteration on a scale of one to five, then brainstorming how to achieve a “five” next time.
- Simple: Discussing and categorizing feedback under specific headings. (Figure 1)
Brainstorming and Action Items: The “Simple” format is the most conventional, typically asking the team to generate stickies for three headings: 1) what went well, 2) what did not go well, and 3) what to do better next time. Teams can adapt this format quickly, adding more questions or categorizing feedback by themes to make all accomplishments and challenges visible. This structure is not just for open brainstorming; its primary purpose is to generate concrete, actionable improvement items.
Voting and Root Cause Analysis: The retrospective concludes by prioritizing these action items. The team votes on the top suggestions for improvement to add directly to the Team Backlog, though broader systemic issues might be escalated to the ART or Portfolio backlog. If a significant issue surfaces, the team may perform a root cause analysis to identify underlying factors and discuss potential corrective actions.
Problem Statements vs. Solutions: Crucially, the resulting backlog items should be framed as problem statements rather than finalized solutions. The retrospective is the time to define when an acceptable solution has been achieved by enshrining it in measurable acceptance criteria. Actually solving the problem takes place later, once the improvement item is pulled into an active iteration timebox.

Read more about the Product Owner and Scrum Master/Team Coach
What is the usual agenda for an Iteration Retrospective?
The timebox for the event is up to one hour for a two-week iteration. An example iteration retrospective agenda (Figure 2) and a description of each item follow.
The retrospective generally has two parts:
- Quantitative review. The team assesses whether the iteration goals were met using a binary (yes/no) measure. Agile Teams collect and review iteration metrics for transparency and to assist with process improvement. Examples include flow metrics, such as flow velocity, load and distribution, defects addressed, and automated test coverage. This data also provides the context for the qualitative section that follows.
- Qualitative review. During the qualitative portion, the team reviews the improvement stories they identified in the last retrospective. They then analyze the current process, focusing on finding one or two things they can do better in the next iteration. Since many improvement items have a significant scope, the team can divide them into smaller improvement stories to be implemented incrementally in subsequent iterations.
What are some examples of improvement stories?
As organizations begin improving their flow of value delivery, Agile Teams will have many improvement opportunities, including:
- Applying SAFe’s built-in quality practices
- Enhancing test automation (including test-driven development and behavior-driven development) and Continuous Integration
- Automating the deployment process
- Decoupling deployment from release (see Release on Demand article)
- Building telemetry and recovery techniques into systems
- Updating shared tools and agents across team members
- Improving communication and techniques for code reviews and demos
Lean-Agile Leaders support Agile Teams in prioritizing capacity to cultivate new skills and address improvement opportunities. The Innovation and Planning (IP) Iteration also offers teams opportunities to advance their skills.
Last Update: 18 March 2026