Project retrospective: questions, agenda and template

What is a project retrospective?

A retrospective is a meeting where a team reviews its experience over a defined period and decides what to change. You can hold one after a project, a phase or a recurring work cycle. Discuss how people worked together, the process and the conditions, without looking for someone to blame.

A status meeting covers what is done and which tasks are late. In a retrospective, ask why the work went the way it did and what small step would help next time. A list of difficulties is only a start. Agree on a result you can check.

Avoid turning the meeting into a defense of a report before management. If participants expect to be punished for speaking openly, they may hold back important details. Explain the purpose and discussion rules in advance.

How to prepare the team

Set the scope, for example, “preparing and launching a training webinar,” rather than “everything that goes wrong.” Invite people who worked on the process and can explain it from different perspectives.

Ask everyone to bring one specific episode: what happened, when, what it led to and what helped. You can collect notes in advance and give people a few minutes to think quietly at the meeting, so the discussion does not start with only the most vocal person’s view.

Have materials ready in case facts are disputed: a plan, task history, approved versions or project correspondence. A missing record does not show that nothing happened. An unsaved comment is not proof that someone failed to act.

Retrospective agenda and questions

This sample time allocation is for a small team. Adapt it as needed. A complex topic may need a separate meeting.

If people start arguing about who usually gets things wrong, bring them back to the episode. Instead of “We never get decent materials,” ask “What material was missing this time, and when did we notice?”

Do not try to solve everything at one meeting. Choose a problem that affects the work and has a practical next step. Record other issues separately so they are neither forgotten nor turned into promises nobody owns.

From a complaint to a testable change

A team was preparing a webinar. One day before launch, it found that several approved edits had not made it into the deck. At the retrospective someone said, “We had to redo everything at the last minute again.” The frustration alone did not point to a solution.

Participants opened the materials and reconstructed the episode. Comments were sent in two chats, some edits were made and there was no shared status. The team thought one list might reveal omissions before final approval.

They agreed to test it on the next training webinar. Marina, the coordinator, creates the list before preparation starts. Each comment is marked “accepted,” “in progress” or “checked,” or gets a reason for rejection. The day before launch, the editor compares the list with the final deck.

At the next retrospective the team checks for approved edits that were still missed and discusses whether the list was easy to maintain. If omissions recur, look for other causes, such as unclear wording or late changes, before blaming the tool.

Retrospective outcome template

Project and period:
Participants:
What helped and what to keep:

Chosen problem:
Observations and specific examples:
Possible cause:
What is still unknown:

Experiment to run:
Owner:
Preparation deadline:
Where progress is recorded:
How we will judge the result:
When we will discuss the result:
Decision after review: [keep / change / stop]

Other topics for the next discussion:

Send the summary to participants and let them correct inaccuracies. If a task depends on a decision from someone who was absent, record that dependency. Get their agreement before assigning the task or recording a promise on their behalf.

• The scope of the discussion is clear.
• Facts are separate from assumptions.
• The team knows what it wants to keep.
• The team has picked a feasible change.
• The owner has accepted the task.
• A time to check the result is set.