At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Note: For more on SAFe Scrum, please read the additional Framework articles in the Scrum series, including SAFe Scrum, Scrum Master/Team Coach, Iterations, Iteration Planning, Iteration Goals, and Iteration Review.
The Iteration Retrospective is a regular event where the team members discuss the results of the iteration, review their practices, and identify ways to improve.
Agile teams that apply 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 next iteration. Agile Teams applying Kanban hold retrospectives whenever needed, but they often use the same cadence as Scrum teams.
Agile Teams reflect on the completed iteration and derive new ideas to improve the team’s process. This reflection helps instill the concept of relentless improvement—a fundamental tenet of the SAFe Core Values, And it helps ensure that every retrospective yields some minor improvements.
Inputs and Outputs of the Iteration Retrospective
Inputs to iteration retrospective may include:
- Iteration goals
- The team’s increment
- List of improvement stories identified and the actions taken since the last retrospective
- Collection of agreed-to iteration metrics
A successful iteration retrospective event delivers the following outputs:
- Creation of a few improvement Stories
- Updated Team Backlog
The Scrum Master/Team Coach should offer the team a way to give feedback on the techniques used at the last retrospective to improve the event’s facilitation.
The entire team participates in the retrospective. The Scrum Master/Team Coach starts the event by introducing the goals of the retrospective, the agenda, and the facilitation format for the meeting.
The team reviews and discusses the metrics the team has agreed to and determines any actions to take, such as further investigation or analysis.
Team members may write their thoughts on a flip chart or the digital tool designated for the retrospective. Following are several popular formats for getting started with qualitative feedback for the iteration (also see , , [4,], ):
- Individual. Individually write post-it notes and then group similar stickies
- Appreciation. Note whether someone has been helpful to the team
- Conceptual. Choose one word to describe the iteration
- Rating. Rate the iteration on a scale of one to five, and then brainstorm how to make the next one a five
- Simple. Open a discussion and record the results under the three headings described next.
The last format is the most conventional. The team creates stickies to record 1) what went well, 2) what did not, and 3) what to do better next time and then facilitates an open brainstorming session.
Of course, teams can examine more than three questions, match the questions to themes, and can use this time to explore new ways of getting feedback and improvement items. The team can adopt the simple format quickly, making all accomplishments and challenges visible. Optionally, the team can use different headings for the simple retrospective, as shown in Figure 1.
The last part of the process is to hold a team vote on the action items and suggestions for improvement to add to the Team Backlog. If a significant issue is identified, the team may perform a root cause analysis, discuss potential corrective actions, and enter improvement stories into the team backlog. (See the ‘problem-solving’ section in the Inspect & Adapt article for more information on root cause analysis.)
Attendees of the iteration retrospective event include:
- The Product Owner (PO)
- Scrum Master/Team Coach
- All team members and other stakeholders or subject matter experts
- Other stakeholders, which may include representatives from other Agile Teams or trains.
Scrum Masters/Team Coaches or POs typically facilitate iteration retrospectives for the team, ensuring they stay within the agreed event timebox.
The timebox for the event is a maximum of 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 if the iteration goals were met using a binary (yes or 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.
Other Improvement Opportunities
As organizations begin implementing DevOps and a Continuous Delivery Pipeline, Agile Teams will have many improvement opportunities, including:
- Applying Built-In Quality
- 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)
- Building telemetry and recovery techniques into systems
Lean-Agile Leaders support the time teams need during each iteration to focus on cultivating new skills and addressing improvement opportunities. The Innovation and Planning (IP) Iteration also offers opportunities for teams to advance their skills.
Keeping Team Members Engaged
Team members are more likely to remain more engaged when retrospective formats are new and varied. For example, teams may choose to rotate the responsibility for facilitating retrospectives. One fun practice is allowing each person to select the retrospective format when it’s their turn to lead. This practice creates shared ownership of the process and keeps the retrospective interesting. Having different themes and templates to focus the retrospective on specific topics can also be fun and valuable. The SAFe Collaborate tool, accessed from the community platform, provides many retrospective templates.
 Sprint retrospective techniques. https://waynedgrant.wordpress.com/2014/02/09/sprint-retrospective-techniques-3/
 Derby, Esther, and Diana Larson. Agile Retrospectives: Making Good Teams Great. Pragmatic Bookshelf, 2006.
 Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007.
 Fun Retrospectives. www.funretrospectives.com
 TastyCupcakes.org. http://tastycupcakes.org/tag/retrospective/
 Agile Retrospective Resource Wiki. http://www.retrospectivewiki.org
Last update: 14 March 2023