Team retrospective: how to run it well

Team retrospective: how to run it, formats and questions

Performance

How to

2026-09-22

PeopleForce Editorial Team

A retrospective is a regular team meeting where people look back at how they worked together over a period and agree what to change in the next one. The conversation is about the process, not the outcome: what got in the way, what helped and where time was lost.

A typical retrospective lasts 45 to 90 minutes and is run by a facilitator. A successful one ends not with a list of complaints but with two or three concrete actions, each with an owner and a deadline. If nothing changes after the meeting, it was a conversation, not a retrospective.

Key facts

Length: 45–90 minutes depending on the period and team size.
Participants: the whole team, ideally up to 10 people.
Outcome: 2–3 actions, each with an owner and a deadline.
The first item of the next meeting is checking the previous actions.

How a retrospective differs from a status meeting and a review

The most common reason retros fail is that they turn into a status meeting or into a judgement of specific people. These are three different formats with different rules.

	Retrospective	Status meeting	Performance review
About	How the team works together	What is done and what is blocked	How one person performs
Frequency	Every 2–4 weeks	Daily or weekly	Every six or twelve months
Who speaks	Everyone equally	Each person about their work	Manager and employee
Tone	Blameless	Informational	Evaluative
Outcome	A change in process	Updated plan	Rating, goals, development decisions
Recorded in	The team's action list	Task tracker	The employee's profile

The key rule: a retro never decides anyone's fate. As soon as the conversation shifts to judging individuals, the team stops speaking honestly, and rebuilding that is harder than starting from scratch.

Who runs the retrospective

The facilitator can be a Scrum Master, team lead, project manager or anyone on the team in rotation. Their job is not to bring ready-made conclusions but to hold the structure and the time.

Parameter	Recommendation
Length	45 min for a two-week period, 90 min for a quarter or a finished project
Frequency	Every 2–4 weeks; less than monthly and context gets lost
Group size	Up to 10 people; split larger groups
Who attends	Those who actually worked in the period
Should a senior manager join?	No, if their presence changes what people say
Format	In person, or online with a shared board and cameras on

How to run a retrospective: five stages

The classic five-stage structure was described by Esther Derby and Diana Larsen in their book Agile Retrospectives, and it works whatever format you choose. Suggested timings for a 60-minute meeting are in brackets.

1. Set the stage (5–10 min)

The facilitator restates the goal, the period under review and the blameless rule. Its classic wording is Norman Kerth's Prime Directive: 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. This is also where you check the actions from the last retro: what was done, what was not and why.

A short check-in question, one word from each person about how they feel, has a practical purpose: whoever does not speak in the first five minutes will most likely stay silent for the whole meeting.

2. Gather data (15–20 min)

The team reconstructs the facts of the period: what happened, what was delivered, where incidents occurred. Everyone writes on their own for 5–7 minutes first, then similar cards are grouped. Writing before discussing is the only way not to lose the thoughts of quieter people.

3. Generate insights (15–20 min)

The most important and most often skipped stage. Look at causes, not symptoms: why a task sat in review for a week, why requirements changed for the third time. A practical technique is to ask “why?” three times in a row for each of the biggest card groups.

4. Decide what to do (10–15 min)

The team picks at most three things to change. Each action is a verb, an owner and a date. “Improve communication” is not an action. “Add an acceptance criteria field to the task template, Sarah, by Friday” is.

5. Close (5 min)

The facilitator reads the agreed actions aloud so everyone hears the same wording, then collects quick feedback on the meeting itself. Asking “was this hour useful?” is a retro on the retro.

Retrospective formats

A format is a way to gather data in the second stage. Change it every three or four meetings, because the same template quickly produces the same answers.

Format	How it works	When to use it
Start / Stop / Continue	Three columns: start doing, stop doing, continue	The default and a team's first retro
Mad / Sad / Glad	Events grouped by the emotion they caused	When there is tension nobody talks about
4L: Liked / Learned / Lacked / Longed for	Four columns on what went well, what was learned, what was missing and what people wished for	After a big milestone or launch
Sailboat	A sailing metaphor: wind, anchor, rocks, island as the goal	When obstacles need linking to the goal
Timeline	Events on a timeline with highs and lows marked	Long periods: a quarter or a finished project

For a new team, start with Start / Stop / Continue: it does not ask people to talk about emotions and leads straight to actions. Mad / Sad / Glad needs trust in the group and an experienced facilitator.

Retrospective questions

A question bank by meeting stage. You do not need them all: two or three per stage is enough.

To open

In one word, what was this period like for you?
Which actions from the last retro did we really complete, and which stayed on paper?
What do you expect from this hour?

To gather data

What worked better than you expected this period?
Where did you lose the most time?
Which task turned out harder than it looked at the start?
What were you missing to finish your part faster?
When did you last wait more than a day for a reply?
What did we do for the first time that is worth repeating?

To find causes

Why did this happen now and not a month ago?
What would have had to happen for us to notice the problem earlier?
Is this a one-off or does it keep happening?
Which of our decisions two months ago led to this?
Who knew about the risk, and why did the information not reach everyone else?
What did we assume at the start that turned out to be wrong?

To decide

Which single change will have the biggest effect on the next period?
What is the smallest step we can take tomorrow?
Who owns it and by when?
How will we know at the next retro that it worked?
What will we stop doing to make time for it?

To close

Does everyone agree with how the actions are worded?
What was left unsaid in this meeting?
What should we do differently in the next retro itself?

How to follow decisions through

Retrospectives stop working not because of bad questions but because agreements are not recorded anywhere. The minimum discipline is four rules.

Three actions at most. Ten items means zero completed items.
Every action has an owner. Not “the team” but a specific name.
Every action has a date. “Soon” is not a date.
The first item of the next retro is checking the last one. Unfinished actions either move with a new date or are consciously dropped.

Actions that concern one person belong in their one-to-one with their manager. In the Perform module, one-to-ones have a separate action list with an assignee, and unfinished items carry over to the next meeting automatically, so an agreement does not disappear between two weeks.

If a retro produces not a small process fix but a change in priorities, it belongs in the goals for the next cycle rather than the meeting's action list. Our guides to OKRs vs. KPIs and employee KPIs cover how to set those up.

Retrospectives beyond Scrum

Retros were born in agile software development, but the format works wherever several people have completed a stretch of work together.

When to run one	What to discuss
After closing a difficult vacancy	Where candidates dropped out, how long they waited for feedback, whether the role was described accurately
After a project ends	Which time estimates were unrealistic and why
After an employee leaves	What in the process could change to spot signals earlier, without discussing the person
After a quarterly goal cycle	Why some goals did not move from the first week
After an incident or outage	The timeline of events and the points where it could have been stopped
After a new hire's onboarding	What in the first month stopped them becoming independent

In all these cases the structure is the same: facts, causes, actions. Only the length of the period changes.

Common mistakes

Turning it into a complaints session. Discussion with no decision kills motivation faster than having no retro at all.
Discussing people instead of the process. After one such retro, the team stops speaking honestly.
Skipping the causes stage. Going straight from symptoms to actions means the same problem returns a month later.
The facilitator talks the most. If a manager runs it with ready-made conclusions, it is a briefing, not a retro.
Not checking past actions. The team quickly learns that agreements mean nothing.
Cancelling when busy. The retro is the first thing dropped from the calendar, exactly when it is needed most.

Agreements that do not get lost

In Perform, actions from one-to-ones have an assignee, and unfinished ones carry over to the next meeting automatically.

Book a demo

Frequently asked questions

What is a retrospective?

A team meeting to discuss how work went over the past period and agree specific changes for the next one. It is about the process, not the people.

How long should a retrospective take?

From 45 minutes for a two-week period to 90 minutes for a quarter or finished project. Beyond two hours, the group loses focus.

Who should run a retrospective?

Anyone on the team who can hold the structure without pushing their own conclusions. Rotating facilitators usually produces livelier meetings than one permanent host.

Are retrospectives useful outside IT?

Yes. The format works for any team that has completed a stretch of work together: recruiting, marketing, support or finance.

How is a retrospective different from a performance review?

A retro is about the team and the process, happens often and does not affect pay. A performance review is about one person, happens every six or twelve months and can affect level and development plans.

What if the team stays silent?

Start with anonymous card writing before discussion, ask about specific events rather than general impressions, and check whether someone in the room makes it hard to speak openly.

How do you run a retrospective online?

The same five stages, with a few rules: open the shared board before the meeting starts, have everyone write cards on their own and anonymously, put a timer on each stage and keep cameras on. If the team spans time zones, pick a shared window and gather data asynchronously the day before, so the meeting itself can focus on causes and decisions.