Project Retrospective

Run a structured look back with your team at the end of a sprint, a phase or a project: what the results were, what worked, what did not and why, and what you will change. You finish with a few changes that have an owner and a date, and a check on whether people said what they really think.

Evidence: structured team debriefs have strong research support (strong); the agile retrospective formats are practitioner codifications of that practice. The mechanism depends on psychological safety, one of the best-supported constructs in team research (strong). Question order, ratings and rituals are craft. Time boxes on this page are rules of thumb.

Use it when:

• A sprint, phase or project has just ended and memories are fresh.
• The same problems keep coming back and last time's lessons were not used.
• You lead a team and want to hear what people do not say in status meetings.

Skip it when:

• You want one review of a whole finished project, with its numbers and knowledge sharing: use 8.20 End-of-Project Review.
• A conflict or a person is the real issue: use 4.6 Conflict & Feedback Guide first.

A retrospective stands on unusually solid ground for a management ritual: structured team debriefs, where a team reconstructs what happened and why, have strong research support, and the agile retrospective formats (Kerth, 2001; Derby & Larsen, 2006) codify that practice. The mechanism has a precondition. A debrief surfaces only what people are willing to say, and whether people speak up about mistakes depends on psychological safety (Edmondson, 1999). The evidence-backed core is regular structured reflection plus a climate where candor is safe. Formats, ratings and rituals are craft.

So pair what went well with a safety check: a glowing retrospective beside low safety is a silence report. Push past individuals to the process, because that is where fixable causes live. Examine leaders as behavior, not as scapegoats or blind spots. Above all, end with owned, dated actions, since the problem that repeats is rarely a lack of lessons; it is a lack of follow-through on the last ones.

Start with facts so the discussion is not only about feelings. Use the goals from the start, not new ones.

Strong answer: (illustrative numbers) "Goal: finish by 30 June. Actual: 14 July (2 weeks late). Goal: within 400,000 SEK. Actual: 380,000." Not: "Mostly delivered."

Project or period, and scope (full project, phase or sprint):

Illustrative example: the project and the numbers are made up.

A project lead at a building contractor in Västerås runs a retrospective after a six-month office renovation that finished two weeks late and under budget.

Step 1: goals against actuals: date missed by two weeks, budget met, no serious accidents.

Step 2: the team writes silently first. Went well: weekly site walks with the client. Did not: late change requests, mostly agreed by phone.

Step 3: why the delay? Changes were not written down, and no one owned the list. It is a process cause, not "the client".

Step 4: safety scores 3 of 5. Two people say they hesitated to raise the delay early. The lead decides to react to early warnings with thanks.

Step 5: three changes: a written change list owned by the site manager, a Friday review, and a rule that scope changes wait for a line in the list.