Retrospective
Origin and purpose
Its origin predates Scrum. The first mention of a similar concept is thought to date back to 1997, when Alistair Cockburn, one of the originators of the Agile Manifesto, introduced it in his book Surviving Object-Oriented Projects. In the book, he discusses the possibility of including a review point after each increment. However, this concept may have a precedent in the field of education: self-assessment is common practice in education, with the aim of understanding how work has been carried out and determining whether it has been effective for learning.
In the case of retrospectives, the goal is very similar. A retrospective meeting focuses on how we are building: how we are working, with the aim of analyzing problems and areas for improvement.
Difference between the Sprint Review and the retrospective
Although they are often held at the end of each sprint, they should not be confused with Sprint Review meetings:
- The goal of the Sprint Review is to analyze what is being built: the increment and the product feedback.
- The goal of the retrospective is to analyze how it is being built: the process, the collaboration, and the ways of working.
Structure
In general, every retrospective follows a structure made up of five phases. There is consensus on the number of phases, although authors such as Derby and Larsen consider the five-phase structure advisable for retrospectives lasting a minimum of one hour and a maximum of three days.
Structuring retrospectives is important because it helps follow the natural order of thought and makes ways of working easier to understand. It helps the team adapt and investigate.
Phase 1: Set the stage
The goal of this phase is to lay the groundwork for upcoming retrospectives and foster a positive atmosphere that is open to discussion. The key point is active participation from the start: if the team does not speak up from the outset, it is less likely to get involved in the rest of the meeting.
Common techniques:
Phase 2: Gathering data
The goal is to build a shared picture of what happened during the sprint: facts, events, emotions, and perceptions. It is important to gather both objective data (what happened) and subjective data (how the team experienced it), because both dimensions are relevant to understanding the sprint as a whole.
Common techniques:
Phase 3: generating insights
The goal is to analyze the data collected in the previous phase to understand why things happened the way they did. The team looks for patterns, root causes, and connections between events. This is the most analytical phase: it moves from "what happened" to "why it happened" and "what it means".
Common techniques:
Phase 4: decide what to do
The goal is to choose the specific improvements the team will implement in the next sprint. The team prioritizes among the options generated in the previous phase and turns reflection into action commitments.
Common techniques:
Phase 5: closing the retrospective
The goal is to close the session on a positive note, thank everyone for their contributions, and gather feedback on the retrospective itself to improve it in the future.
Common techniques:
Factors for Designing Retrospectives
Context
The design of the retrospective should take into account the size of the team, the time elapsed since the last retrospective, the team's mood, whether there are difficult issues pending, and the team's maturity in agility. A team that has spent many sprints with the same dynamics may need variety; a new team may need simplicity and a clear structure.
Time
The total time available determines how many activities fit in and how deeply each phase can be explored. Derby and Larsen recommend one hour for short retrospectives and up to three hours for full retrospectives. Beyond three hours, throughput drops significantly.
Structure
The sequence of activities should flow coherently: earlier phases provide the material for the following ones. Changing the order of the phases rarely works well. What can be adjusted is the relative time devoted to each phase, according to the team's needs.
Space
The physical or virtual space has a significant impact on the quality of the conversation. A space that encourages movement, allows everyone to see each other, and has walls available for sticky notes produces better retrospectives than a meeting room with a long table in the middle. For remote teams, the digital whiteboard tool is the equivalent of the physical space.
Choice of Practices
Activities should be chosen based on the context and the goal of each phase, not out of habit or convenience. Varying the techniques from one retrospective to the next keeps the team engaged and makes it possible to explore different dimensions of the sprint.
Leadership
Every retrospective needs a facilitator. The Scrum Master usually takes on this role, although in mature teams any member can facilitate it. The facilitator:
- Designs the session in advance.
- Manages the time for each activity.
- Creates a psychologically safe space so that the team can express themselves honestly.
- Does not take part in the content of the discussions: their role is to facilitate the process, not to influence the conclusions.
Retrospective Activities
The Scrum Manager BoK includes techniques for each of the five phases:
| PHASE 1 | PHASE 2 | PHASE 3 | PHASE 4 | PHASE 5 |
|---|---|---|---|---|
| Focus, discuss, and foster a safe environment. | Gather information. | Identify areas for improvement and generate ideas. | Generate action plans. | Reflect on and recognize individual and team work. |
Useful materials
🔧 Diseñar una retrospectiva [Designing a retrospective] (in Spanish)Template · Scrum Manager
📄 Cómo diseñar una sprint retrospective [How to design a Sprint Retrospective] (in Spanish)Scrum Manager Blog · Oct 2022
📄 Primera fase de una retrospectiva [First phase of a retrospective] (in Spanish)Scrum Manager Blog · Jun 2023
📄 Segunda fase de una retrospectiva [Second phase of a retrospective] (in Spanish)Scrum Manager Blog · Aug 2023
📄 Tercera fase de una retrospectiva [Third phase of a retrospective] (in Spanish)Scrum Manager Blog · Oct 2023
Common mistake
Holding retrospectives without implementing any of the agreed actions. A retrospective that produces no real change in the next iteration gradually stops being useful: the team learns that the session is pointless and stops committing. If the team cannot implement all the agreed actions, it is better to agree on fewer and carry them all out.
References
- Cockburn, Alistair. (1997). Surviving Object-Oriented Projects. Addison-Wesley.
- Derby, Esther; Larsen, Diana. (2006). Agile Retrospectives: Making Good Teams Great. Pragmatic Bookshelf.
See also
Want to advance in agility? You can search for calls for courses and exams, or go at your own pace by becoming a member of the Agile Club. This membership includes exclusive resources, e-learning classrooms, and access to Skill Arena: a space to practice and measure your agile skills at your own pace.