A retrospective is a regular, timeboxed inspection of how the work is being done, held by the people doing it and ending in a change they will make. It is the mechanism by which a team improves at its own process as well as at its subject, and it is the practice PMI has in mind when the examination refers to continuous improvement. The name and the practice come from adaptive delivery, where Scrum requires one at the end of every Sprint, and Norman Kerth's book of 2001 gave the meeting its modern form.
Frequency is where the value lies. A team that examines its working every two weeks makes twenty six small corrections in a year, each of them on evidence still fresh enough to be accurate. A team that does so once at the end produces a document for a project that has already finished. The sections below describe what the meeting has to produce, a structure that reliably produces it and how the improvement travels beyond one team.
Why the output has to be a change
The failure mode is a session that generates a list. Things that went well, things that did not, all of it filed, and then the same list appears at the following session.
What prevents this is a limit on the output. One change, occasionally two, specific enough that anybody can tell afterwards whether it happened, and with a name against it. A team that attempts six improvements at once will implement none of them, and the experience teaches everybody that retrospectives do not work.
Each following session then opens by checking the last change. Did it happen, did it help and should it stay. That single habit turns a series of meetings into a process, because it makes the previous session's decision consequential.
The five stage structure
Getting to one owned change reliably needs a structure, and the one most teams use has five stages.
| Stage | Purpose | What it prevents |
|---|---|---|
| Set the stage | Get everybody speaking early and agree what the session covers | A session where two people talk and the rest observe |
| Gather data | Establish what actually happened, with facts before opinions | An argument between competing recollections |
| Generate insight | Ask why the data looks like that, and look for the causes underneath the events | Fixing a symptom that recurs in a different form |
| Decide what to do | Choose the change, name the owner, agree how it will be visible | A list of good intentions |
| Close | Confirm the decision and check how the session itself went | The same unproductive format repeating for months |
Gathering data before generating insight is the stage most often skipped and the one that does most of the work. A session that begins from opinions will debate opinions. A session that first establishes what happened, when, and what the measures showed usually discovers that the disagreement was about facts, and facts can be checked.
Making the retrospective safe enough to be useful
The data stage only works where people are able to name the real problems without cost. Where a manager who conducts appraisals is in the room, or where a previous session led to someone being blamed, the team will discuss tooling and avoid the working relationship that is the actual constraint.
Two practical measures help. The first is to keep the session to the team, and to escalate whatever needs escalating as a separate act afterwards. The second is to treat every account as an honest attempt given what that person knew at the time. This turns the question from who did this into what made this the reasonable thing to do.
Root cause analysis and where it stops
The insight stage asks why, repeatedly, and each why moves the discussion from an event to a cause. A missed date becomes a late dependency, which becomes a request raised too late, which in turn becomes a planning conversation that does not include the team supplying the work.
The questioning stops at the last cause the team is able to do something about. Continuing past that point produces a conclusion about organisational structure that is probably true and entirely unactionable, and a session that ends there has taught the team that the problem lies beyond them.
Continuous improvement beyond the team
Some causes genuinely do lie beyond the team, and a retrospective improves only one team. Improvement across an organisation needs the findings to travel, and this is where most of the value is lost.
What travels is a repository that someone actually searches, and most repositories are never searched. A repository is worth keeping on two conditions. The entries must be written for a reader, which means the situation, what was tried, what happened and what to do differently. Someone must also be responsible for bringing relevant entries forward at the start of new work.
There is also a structural route. Where three teams independently identify the same blocker, the fix belongs to whoever owns the thing that blocks them, and carrying that pattern upward is a project manager's job.
Where each syllabus puts it
Scrum requires a retrospective at the end of every Sprint, timeboxed and attended by the whole team, and requires that at least one improvement be added to the following Sprint's work. Lean approaches treat the same activity as kaizen, which is a standing expectation of small continuous change. Predictive practice has historically placed the equivalent at phase gates and at closure.
PMI expects continuous improvement throughout the project. Examination questions usually test the distinction between a review and a retrospective, who belongs in the room and whether the candidate treats an improvement as something owned or merely as something noted.