Retrospectives
The retrospective is the recurring meeting in which the whole team examines its own way of working and decides what it will change for the next period. It is held at the end of each iteration or release. Where a team does not work in fixed cycles, the session is scheduled at a regular interval. It runs in two parts: the team looks back at the iteration just closed, then identifies adaptations. It bears on the process; the Agile Extension to the BABOK Guide keeps anything personal out of the discussion. Each session opens on the actions decided the time before and closes on a few new ones, each carrying a deadline and a member of the team who answers for it. In Scrum, the sprint retrospective is this session: it closes the sprint and runs to at most three hours for a one-month sprint.
Goal
The retrospective is the meeting in which a team examines its own working process and decides what it will change in it. The Agile Extension to the BABOK Guide sets the purpose: reflect on what went well and what could go better, then improve the processes. The session brings together the whole team, the one that ran the process under examination and that will apply whatever is decided.
What separates the technique from a one-off review is the loop. The first element of the session is the review of the actions decided at the previous retrospective, whose progress and effect the team measures. Without that examination nothing links the sessions: the same subjects come back from iteration to iteration.
The Agile Extension places the retrospective at the Initiative and Delivery horizons: the team draws the lessons of the delivery cycle just closed and decides what to change, keep or stop in the next one. Table 7.0.1 lists it among the communication techniques that work with internal teams, without naming it for external stakeholders.
The boundary with lessons learned
The BABOK's lessons learned are the closing review of a project or a phase: it happens once, reaches beyond the team and produces a register the organisation reuses on its next initiatives. The retrospective comes back every iteration, stays inside the team and produces a few actions for the period about to start.
Usage
When to use it
- End of an iteration or a release: anchor the learning in the process before the next cycle.
- Team working without fixed cycles: schedule the session at a regular interval to keep the process under examination.
- Milestone in the solution's life cycle: a go-live or the end of a phase warrants a session outside the cadence.
- Disagreement raised at the time and left undecided: settling how the team works is for the whole team.
When not to use it
- Problem visible during the iteration: deal with it there and then.
- Subject to settle with an external stakeholder: the retrospective is an internal session, take it to the sprint review.
- Appraisal of one person's performance: the session bears on the process, the individual review belongs to line management.
Description
The five elements
The Agile Extension distinguishes five elements.
| Element | What the team does there |
|---|---|
| Review of the previous actions | Take up the actions decided at the previous retrospective and assess their progress and their effect. |
| Preparation | Before the session, each person gathers the observations from the closed iteration that deserve analysis. |
| Safety Check | The team agrees to trust one another and to take every remark as aimed at improving its performance. |
| Identification of the points | Every member writes down what worked well, what needs improving and what deserves sharing. The Agile Extension names this as the most common mechanism. |
| Choice of the actions | Once the discussion is exhausted, the team settles on the improvements to carry out, fixes a schedule and names for each one the member who answers for it. |
The Safety Check
The Safety Check is the explicit agreement by which the team gives itself the right to speak. The Agile Extension names its limit: members may feel obliged to feign a trust they do not have. The most widespread wording of that agreement is Norm Kerth's Prime Directive, read out as the session opens: "Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand." It comes from the retrospectives literature; neither anchor prescribes it.
The Agile Extension holds it useful to hand the facilitation to a neutral facilitator from outside the team, without making it an obligation: it counts among the technique's strengths that a team can facilitate the session itself.
The session format comes from practice
Neither the Agile Extension nor the Scrum Guide defines a facilitation format. The Agile Extension gives one common mechanism for identifying the points and stops there. The formats in use come from practice and from the literature: Esther Derby and Diana Larsen supply the reference structure in five stages, set the stage, gather data, generate insights, decide what to do, close the retrospective. A team that keeps the same format every iteration gets the same answers after a few cycles, since the question is the same.
The sprint retrospective in Scrum
The Scrum Guide gives the sprint retrospective a purpose: to plan ways of increasing quality and effectiveness. The Scrum team examines the sprint just closed from the angle of individuals, interactions, processes, tools and its Definition of Done, the criteria an increment must satisfy to count as finished. It identifies the assumptions that led it astray and explores where they came from, then discusses what went well, the problems and how they were or were not solved.
It then settles on the changes most useful to its effectiveness and takes up the most telling ones at the earliest opportunity, entering them in the Sprint Backlog of the next sprint if need be. A Definition of Done revised following that examination is one of the outputs of the session. The retrospective closes the sprint. Its duration is capped at three hours for a one-month sprint; for a shorter sprint the session is usually shorter.
What makes a retrospective fail
Safety in appearance only
The session takes place, everyone speaks and nothing that matters is said. The sign is a list of actions that never touches the subjects the team airs in the corridor. Handing the facilitation to someone from outside, as the Agile Extension suggests, is the simplest counter, since running the discussion stops belonging to the team.
Actions with no follow-through
The Agile Extension sets the condition: the retrospective has value only if the team acts on what it learns. The fifth element asks for a deadline and an owner on each action; what carries neither comes back unchanged to the next session. The Agile Extension names the cost of a subject raised and then left unanswered: a risk to the team's morale and motivation.
The session that replaces day-to-day handling
Most of the ideas raised in a retrospective are already known to at least one member of the team. The Agile Extension draws a requirement from that: a mature team handles its problems as they arise instead of holding them back for the session. The retrospective then serves to decide on process changes.
AI considerations
A language model groups the notes of the session: it brings together the wordings that say the same thing and produces a list of themes ordered by frequency. On the action register it flags the ones carried over three times without moving, information a team loses from one iteration to the next. It also proposes facilitation formats and writes the questions for one stage of the session.
What stays with the team is the heart of the technique. The Safety Check is an agreement between people and is delegated to no tool. Automatic grouping smooths disagreements away, while the gap between two wordings is often the subject: two members describe the same incident and one puts it down to the tool, the other to the decision that imposed it. The choice of actions commits the team's capacity for the next iteration and belongs to the team. The notes of a retrospective finally carry judgements about named colleagues: they are personal data within the meaning of the Federal Act on Data Protection (FADP), to be handled as such before any transfer to an external service.
Examples
A team of six at a health insurer in French-speaking Switzerland delivers the customer portal in two-week sprints. The retrospective of sprint 24 is facilitated by a business analyst from another team on the same programme, a service the two teams have done for each other for three sprints. It opens on the actions decided in sprint 23.
| Action decided in sprint 23 | Owner | Status and effect |
|---|---|---|
| Bring the number of people on call on go-live day down to two | Nadia | Done. Two interruptions during the sprint, against seven in sprint 22. |
| Document the switchover procedure for the tariff database | Marc | Not done, carried over for the second time. |
| Try reviewing code in pairs on the pricing tickets | Sarah | Done, then dropped: waiting for a reviewer cost more than the time it saved. |
The least obvious row of the table is the pair review: the team tried it, measured it and stopped; the subject is closed for the sprints that follow. The switchover procedure sets off for a third sprint, with two names and a half-day blocked in the calendar, because re-entering the same wording had already failed twice. The team then identifies its points and settles on three actions.
| Point raised | Action settled for sprint 25 | Owner | Deadline |
|---|---|---|---|
| Three pricing tickets blocked for several days waiting for a business answer | A thirty-minute slot on Tuesday and Thursday with the product owner for the open questions | Ana | From the first day of the sprint |
| The test environment goes down at the end of the sprint, when everyone is deploying to it | Measure the load on the environment over the sprint and report the figures at the next session | Julien | Report at the sprint 25 retrospective |
| The tariff switchover is still documented by one person only | Write the procedure in a pair during a half-day blocked in the calendar | Marc and Sarah | Middle of the sprint |
These two tables are the complete product of the session. The second will be read line by line in sprint 25, which is what keeps it short.
Visualisations
Two things lend themselves to a drawing. The first is the loop: an iteration, the retrospective that closes it, the next iteration, then the retrospective that starts by rereading the actions of the previous one. The drawing closes on itself and shows the actions passing from one session to the next, which a list of steps set out in a line does not.
The second is the product of the session. Set in two tables, the register is read again in a minute at the next session and brings out what a continuous list lets through: the action entered for the third time.
Cost
| Phase | Level | Justification |
|---|---|---|
| Preparation | Low | Each person gathers their observations from the iteration; the facilitator picks the format and reopens the action register. |
| Execution | Medium | The session ties up the whole team, up to three hours for a one-month sprint according to the Scrum Guide, and the outlay comes back every iteration. |
| Documentation | Low | The product is a list of actions with dates and owners, kept where the team will see it again. |
Tooling
Collaborative whiteboards (Miro, Mural, FigJam and their equivalents) carry the session remotely: columns, movable notes, grouping by theme and a vote to choose what gets discussed. A co-located team gets the same result with a wall and sticky notes, provided the actions settled on are copied the same day into a medium that survives the week.
Retrospective tools (Retrium, TeamRetro, Parabol and their equivalents) add ready-made formats, a timer per stage, anonymous contributions and the history of the actions from one session to the next. Anonymity helps while trust is still being built; the Safety Check remains to be concluded in the room.
Backlog tools (Jira, Azure DevOps, GitLab and their equivalents) take in the actions settled on, in the place the team looks at every day. The Scrum Guide allows the most telling improvements to be entered in the Sprint Backlog of the next sprint, which gives them the same standing as the rest of the committed work.
Sources
- IIBA, Agile Extension to the BABOK Guide, §7.14 Retrospectives: the purpose of the technique, the session in two parts, the participation of the whole team, the end-of-iteration or end-of-release cadence and the regular cadence in the absence of fixed cycles, the non-personal character of the discussion, facilitation by a neutral facilitator, the five elements, together with the strengths and limitations stated, among them feigned trust, value conditional on action and the risk to morale of a subject left unanswered.
- IIBA, Agile Extension to the BABOK Guide, §7.0, table 7.0.1 Selecting the Right Technique: the retrospective placed among the communication techniques that work with internal teams.
- IIBA, Agile Extension to the BABOK Guide, §5.7.1 and §6.7.1 (techniques by planning horizon) and §6.3.4 (learning at the Delivery horizon): the retrospective at the Initiative and Delivery horizons, together with the examination of what to change, keep or stop in the next delivery cycle.
- Ken Schwaber and Jeff Sutherland, The Scrum Guide (November 2020), "Sprint Retrospective" section: the purpose of the event, the elements inspected, among them the Definition of Done, the assumptions that led the team astray, the choice of the most useful changes and their possible entry in the Sprint Backlog, the closing of the sprint and the three-hour cap for a one-month sprint.
- Norm Kerth, Project Retrospectives: A Handbook for Team Review, Dorset House, 2001: the Prime Directive, the reference wording of the agreement the Agile Extension calls the Safety Check.
- Esther Derby and Diana Larsen, Agile Retrospectives: Making Good Teams Great, Pragmatic Bookshelf, 2006: the five-stage facilitation structure that neither the Agile Extension nor the Scrum Guide defines.