At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
The Iteration Retrospective is a regular event where Agile Team members discuss the results of the Iteration, review their practices, and identify ways to improve.
At the end of each iteration, Agile teams that apply ScrumXP (and many teams who use Kanban) gather for an iteration retrospective. Timeboxed to an hour or less, each retrospective seeks to uncover what’s working well, what isn’t, and what the team can do better next time.
Each retrospective yields both quantitative and qualitative insights. The quantitative review gathers and evaluates any metrics the team is using to measure its performance. The qualitative part discusses the team practices and the specific challenges that occurred during 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 team’s process. This helps instill the concept of relentless improvement—one of the pillars of the SAFe House of Lean—in the individuals and the team. And it helps ensure that every iteration yields some small improvements.
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 review – The team assesses whether they met the Iteration Goals and this is a binary measure: yes or no. Agile teams collect and apply Iteration Metrics for visibility and to help with process improvement. Examples might include team velocity, number of stories delivered, defects addressed, capacity allocation across new work and maintenance and automated test coverage. This data is also the context for the qualitative section that follows.
- Qualitative review – First the team reviews the improvement stories they had identified in the prior retrospective, and 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 items have a significant scope, the team should divide them into smaller improvement stories, so that they can focus on what they can improve during subsequent iterations.
- Test automation (including Test-Driven Development and Behavior-Driven Development) and Continuous Integration
- Improving architecture and design quality (see Architecture and Design Quality section of Built-In Quality)
- Automating the deployment process
- Decoupling deployment from release (see Release on Demand)
- Building telemetry and recovery techniques into systems
Lean-Agile Leaders are responsible for preserving and protecting the time teams will need during each Program Increment (PI) to focus on cultivating these skills, in addition to delivering new features. The Innovation and Planning (IP) Iteration is a great time to create opportunities for teams to advance their skills in these new domains.
There are several popular techniques for eliciting subjective feedback on the success of the iteration (also see , , [4,], ):
- 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 one to five, and then brainstorm how to make the next one a five
- Simple – Open a discussion and record the results under three headings
The last is a conventional method, in which the Scrum Master simply puts up three sheets of flipchart 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.
Teams may choose to rotate the responsibility for facilitating retrospectives. If this is done, one of the fun practices is to allow each person to choose the retrospective format when it’s their turn to lead. This not only creates shared ownership of the process, but it also keeps the retrospective fresh. Team members are more likely to remain engaged when formats are new and varied.
Below are some tips for holding a successful iteration retro:
- Keep the event timeboxed to an hour or less. Remember, it is repeated every iteration. The goal is to make small, continuous improvement steps.
- Pick only one or two things that can be done better next time and add them as improvement stories to the team backlog, targeted for the next iteration. The other opportunities for improvement can always be addressed in future iterations if they continue to surface in retrospectives.
- Make sure everyone speaks.
- The Scrum Master should spend time preparing the retrospective, as it’s a primary vehicle for improvement.
- Focus on items the team can address, not on how others can improve.
- To show progress, make sure improvement stories from the previous iteration are discussed either at the Iteration Review or the beginning of the quantitative review.
- The retrospective is a private event for the team and should be limited to Agile team members only.
Learn More 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: 28 December 2019