At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Iteration Retrospective Abstract
At the end of each iteration, Agile Teams that apply Scrum (and many teams who use Kanban) gather for an Iteration Retrospective, where the team members discuss their practices and identify ways to improve. Timeboxed to an hour or less, each retrospective endeavors to uncover what’s working well, what isn’t, and what the team can do better next time.
Each retrospective has both quantitative and qualitative aspects. The quantitative review gathers and reviews any metrics the team is using to measure its performance. The qualitative part discusses the various team practices and the specific challenges that presented themselves in the course of the last iteration or two. When issues have been identified, root cause analysis is performed, potential corrective actions are discussed, and improvement stories are entered into the Team Backlog.
The Iteration Retrospective is used by Agile Teams to reflect on the Iteration just completed and to derive new ideas to improve the process. This helps instill the concept of relentless improvement—one of the pillars of the SAFe Lean-Agile Mindset—in the individuals and the team, and it helps ensure that every iteration makes some small improvements in the team’s process.
The whole team participates in the retrospective, with the Scrum Master facilitating and applying the tools and processes for data collection and problem-solving. The team conducts the retrospective in two parts: quantitative and qualitative.
Quantitative review: The team assesses whether they met the Iteration Goals. This is a binary measure: yes or no. They also collect any other metrics they have agreed to analyze. This must include velocity—both the portion that is available for new development and the portion devoted to maintenance. Agile Teams collect and apply other Iteration Metrics for visibility and to help with process improvement. This data also serves as context for the qualitative section that follows.
Qualitative review: First the team reviews the improvement stories they had identified in the prior retrospective, then analyzes the current process, with a focus on finding one or two things they can do better in the next iteration. Since many improvement stories are significant in scope, the team should divide them into smaller improvement stories, so that they can focus on what they can improve in an iteration.
There are several popular techniques for eliciting subjective feedback on the success of the iteration (also see ):
- Individual – Individually write Post-Its and then find patterns as a group
- Appreciation – Note whether someone has helped you or helped the team
- Conceptual – Choose one word to describe the iteration
- Rating – Rate the iteration on a scale of 1 to 5, and then brainstorm how to make the next one a 5
- Simple – Use three columns and open discussion
The latter is a common method, whereby the Scrum Master simply puts up three sheets of paper, labeled What Went Well, What Didn’t, and Do Better Next Time, and then facilitates an open brainstorming session. It can be conducted fairly easily, making all accomplishments and challenges visible, as illustrated in Figure 1.
A sample iteration retrospective agenda follows:
Part 1: Quantitative
Did the team meet the iteration goals (yes/no)?
Collect and review the agreed-to iteration metrics.
Part 2: Qualitative
Review the improvement stories from the previous iteration. Were they all accomplished? If not, what do we want to do about them?
For this iteration, analyze:
- What went well?
- What didn’t go so well?
- What we can do better next time?
Below are some tips for holding a successful iteration retro:
- Keep the meeting timeboxed to an hour or less. Remember, it will come up every two weeks and the goal is small, continuous improvement steps.
- Pick only one or two things that can be done better next time and add them as improvement stories, targeted for the next iteration.
- Make sure everyone speaks.
- The Scrum Master should spend time preparing the retrospective, as it is a primary vehicle for improvement.
- Focus on items the team can address, not on how others can improve.
- Make sure improvement stories from the previous iteration are reviewed at the beginning of the quantitative review to show progress.
- This is a private meeting for the team and should be limited to team members only.
 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. Chapter 15, “Regular Reflection and Adaption.”
Last update: 28 October 2015