Retrospective meeting questions that surface the truth

A retrospective is worth holding only if something changes as a result, and people can say the real thing without paying for it. The standard went-well / went-badly format produces neither: it collects safe observations and generates a list nobody owns. The questions below are designed to get past the safe answer, and what makes them work is the format rather than anyone’s good intentions: write silently first, share after, and leave with at most two changes that have names and dates on them.

The questions, and the formats

Pick one format per retro rather than mixing. The questions are the variable worth changing — running the same two questions every month is how a retro becomes a ritual people wait out.

Open by checking last time

Last retro we agreed [x]. Did it happen? If not, why not? Do this first, every time, out loud. A team that has watched agreed changes quietly not happen will give you safe answers from then on, and they are right to.

The silent write

Five minutes, everyone writes, nobody speaks. This is the format rule that matters most. Discussion-first retros are anchored by whoever talks first and by whoever is most senior; silent-write-first gets you the quiet person’s observation, which is disproportionately the useful one.

Questions that get past the safe answer

What did we all know was going to happen? · What did we do because we have always done it? · Where did we get lucky? · What would we do differently if we started this on Monday? The luck question is the best single question on this page: teams routinely bank luck as competence and then plan on it.

Questions about the work, not the people

Where did a handoff drop something? · What did we find out too late? · Which decision would we make differently with what we know now? · What did we spend time on that turned out not to matter?

Format — the timeline

Draw the project on a wall as dates, then everyone adds events and how they felt at each. It is slower and it is the best format for finding the moment things went wrong, which is frequently well before anyone noticed.

Format — start / stop / continue

Fast and shallow, and fine for a routine fortnight. Do not use it after something went badly — it is too tidy a container for a real problem and it will produce a tidy, useless answer.

Format — the pre-mortem, run backwards

It is six months from now and this failed. Write the reason. Works as a retro as well as a planning tool, because people will write in that frame what they would not say as a criticism.

Blameless, without being vague

Blameless means the system is on trial, not the person — it does not mean nothing gets named. "The deploy went out untested" is a fact and belongs in the retro. "Sam did not test it" is a personnel conversation and belongs somewhere else, on the same day, in private. Conflating the two is how retros become both useless and unkind.

The close

Two changes. [Change] — [owner] — by [date]. Reviewed at the next retro. Two. A retro that generates eleven improvements has generated a document, and the next retro will open by discovering that none of them happened.

Questions

What questions should I ask in a retrospective?

Ask what everyone already knew was going to happen, where you got lucky, what you did out of habit, and what you found out too late. Those get past the safe answers that went-well / went-badly collects.

What is a blameless retrospective?

One where the system is examined rather than the individual. It does not mean avoiding specifics — facts about what happened belong in the retro. Judgements about a person belong in a private conversation, usually the same day.

How long should a retrospective be?

An hour for a fortnight of work, ninety minutes after a project. Longer sessions produce more items and not more change, and the item count is not the measure of a good retro.

How many actions should come out of a retro?

Two at most, each with a named owner and a date, reviewed at the next one. A long list is functionally identical to an empty one, and the team learns that quickly.

Should retrospectives be anonymous?

Silent writing first gets most of the benefit without the cost of full anonymity, which makes follow-up impossible. If people genuinely cannot say things with their name attached, that is the finding, and it is bigger than the retro.

Why do retrospectives stop being useful?

Almost always because agreed changes do not happen. Opening each retro by reviewing the last one’s commitments is the single fix, and it works because it makes the failure visible to the person who owns it.

A retro is usually the wrong place to have a recorder running: people calibrate what they say to who might read it later, and candour is the only thing a retro produces. Write the two changes down and let the rest be unrecorded on purpose.