What are the three questions of a retrospective?

The most common format asks: what went well, what did not go well, and what will we do differently. Some teams phrase them as start, stop and continue. Either way, the answers should end in specific actions with owners.

What is the difference between a sprint retrospective and a project retrospective?

A sprint retrospective happens at the end of each short iteration and looks at the last few weeks. A project retrospective happens at the end of a whole project and looks at it from start to finish, so it often covers planning, scope and stakeholder management as well as delivery.

Is a retrospective the same as a post-mortem?

They are closely related. A post-mortem usually follows a specific failure, such as an incident or a missed launch, and traces what happened and why. A retrospective is held regularly whether things went well or badly. Both should end in owned action items.

Who should attend a project retrospective?

The people who did the work, plus a facilitator. The project lead attends; senior stakeholders can be invited when the topics need them, but their presence can make people less candid, so decide deliberately.

How long should a retrospective take?

Long enough to agree a few good actions. A sprint retrospective often fits in under an hour; a retrospective covering a whole project or a serious incident may need longer and some preparation beforehand.

How do you make retrospective actions actually happen?

Keep them few, give each one owner and a due date, put them in the task system the team already uses, and start the next retrospective by reviewing them. Actions that live only in meeting notes are usually forgotten.

Free template · no sign-up

Project retrospective template

A project retrospective is a meeting, and the record of it, in which the team looks back at a project or sprint to agree what went well, what did not, and what it will change next time. The output that matters is a short list of action items, each with an owner and a due date.

Hold one at the end of every sprint, at the end of a project, or after an incident or a missed deadline. A retrospective that produces observations but no owned actions changes nothing; this template puts the action table first for that reason.

The CSV is the “Action items” table; it opens in Excel, Google Sheets or Numbers.

#When to use it

When to use a project retrospective template

A sprint, release or project has just finished.
Something went wrong, such as a missed deadline, an incident or an unhappy client.
Something went unusually well and you want to repeat it on purpose.
The same problems keep coming up across projects.

#The template

The project retrospective template

Fill in the blanks and replace the example rows with your own. Everything below is what the copy and download buttons give you.

Context

Project or sprint:
Period covered:
Facilitator:
Attendees:
Objective, and whether it was met:

What went well

Specific things worth repeating.

What went well — example or evidence:
What went well — example or evidence:

What did not go well

Describe what happened and its effect. Focus on the process, not on people.

What happened — its effect:
What happened — its effect:

What we will change

Turn the biggest problems into changes. Vote if there are too many; pick the top few.

Change — which problem it addresses:
Change — which problem it addresses:

Action items

Two to five actions is plenty. Each one changes how the team works, has one owner and a due date.

Task	Why (what it fixes)	Owner	Due date	Status
Add a scope-change step that goes through the sponsor	Late scope changes squeezed testing	Project lead	2026-12-18	Not started
Book design reviews before engineering starts each feature	Rework when designs changed mid-build	Designer	2026-12-18	Not started
Write a one-page handover checklist for releases	Release steps lived in one person's head	Engineer	2027-01-08	Not started

Follow-up on last retrospective

Actions from last time, and whether each was done:
Did they help?

#How to fill it in

How to fill it in

01
Set the ground rule
Open by saying the retrospective is about how the team works, not who is to blame. People only describe problems honestly when they are safe to.
02
Review last time's actions
Check whether the previous retrospective's actions were done and whether they helped. This is what turns retrospectives into improvement rather than a ritual.
03
Gather what went well and what did not
Give everyone a few minutes to write their own notes before discussing, so the loudest voices do not set the agenda.
04
Group, then pick the few that matter
Cluster similar points and vote. Work on the top two or three; a long list of changes is a list nobody does.
05
Write actions with owners and dates
For each chosen problem, agree a specific change, one owner and a due date, and record what it is meant to fix.
06
Track the actions like real work
Put the action items into the team's task list, not just the meeting notes, and review them at the start of the next retrospective.

Common mistakes

Ending with observations but no owned actions.
Turning it into a search for someone to blame, which stops people speaking up.
Trying to fix ten things at once and finishing none.
Never checking whether last time's actions were done.

#In Kavanah

Retro actions that do not get lost in the notes

The weak point of most retrospectives is the follow-through. In Kavanah the action items become tasks on the same board as everything else, so they are seen, owned and finished.

Import this CSV as tasks

Download the CSV and use Import CSV on a project's Integrations tab. The Task, Owner, Due date, Status, Priority and Tags columns become task fields; a row with no task name is skipped.

Learn more

Make the routine repeat

A project's Recurring tab holds rules that create tasks on a schedule, such as every Monday or the 1st of each month, so the routine does not depend on someone remembering it.

Learn more

Discussion threads on the project

Each project has threaded discussions separate from chat, a natural home for the retrospective's notes next to the tasks they produce.

Learn more

Follow-ups that stay tracked

Why post-incident and retrospective follow-ups slip, and how to keep them on the board until they are done.

Learn more

#Questions