# How to run a retrospective that changes something

> A retrospective is only worth it if something changes afterwards. Learn a simple format, how to run it in an hour and how to follow through.

A retrospective is a regular, honest look back at how the team worked. It is worth the hour only if it ends with one or two changes that someone owns.

Web page: https://kansohq.app/guides/how-to-run-a-retrospective

Updated: 5 October 2026

## What a retrospective is for

A retrospective, or retro, is a meeting held at the end of a sprint, a release or a project to ask: what went well, what did not and what should we change? It is how a team improves its own way of working, a little at a time.

## A format for an hour

1. **Set the tone (5 minutes).** State the aim and remind everyone that the point is the process, not the people.
2. **Check last time’s changes (5 minutes).** Did we do what we said we would? What happened?
3. **Collect what went well and what did not (15 minutes).** Everyone writes first, on their own, then the notes are grouped. Writing first stops the loudest voice from setting the agenda.
4. **Pick the few that matter (10 minutes).** Vote, and discuss only the top two or three.
5. **Decide what to change (20 minutes).** For each topic, agree one change that is small enough to try next sprint.
6. **Close (5 minutes).** Read back the changes, each with an owner and a date.

## What makes a retrospective useful

- **Safety.** People only say what is true when they are not afraid of the answer. Keep it blameless.
- **Few changes.** One or two changes that happen beat ten that do not.
- **Owners.** Every change has a name and a date. “We should” belongs to nobody.
- **Follow-through.** Start the next retro by checking the last one’s changes.

**A change that is small enough to try**

> Not: “Improve communication.”
> But: “Post a two-line status in the team channel each morning, starting Monday. Owner: the team lead. Review at the next retro.”

## Keep it fresh

The same questions in the same order get stale. Change the shape now and then: ask what to start, stop and continue; ask for the one thing that slowed you down most; or look at a timeline of the sprint and mark the moments that felt good or bad. Rotate who runs it.

## Mistakes to avoid

- Skipping it when the team is busy. That is when it matters most.
- Ending with a long list of actions that nobody owns.
- A manager running it who then judges what people said.
- Never looking at the changes from last time.

## Formats to rotate through

| Format | How it works | Good when |
| --- | --- | --- |
| Went well, did not, change | Three columns, then pick the changes | You want a plain default |
| Start, stop, continue | What to begin, drop and keep doing | The team needs to make decisions about habits |
| Four Ls | Liked, learned, lacked, longed for | You want more than complaints |
| Sailboat | What is the wind, what are the anchors, where are the rocks | The team needs to talk about risks and blockers |
| Timeline | Mark the high and low points of the sprint on a line | Something big happened and the team needs to look at it |

## A 45-minute agenda

| Minutes | What happens |
| --- | --- |
| 0 to 5 | Set the aim. Read last time’s changes and how they went |
| 5 to 15 | Everyone writes notes on their own: what went well, what did not |
| 15 to 25 | Group the notes, then vote for the two or three that matter |
| 25 to 40 | For each one, agree one small change, with an owner and a date |
| 40 to 45 | Read the changes aloud, and say who will check them next time |

## Remote retrospectives

- Use a shared page where everyone writes at once, so people are not waiting for a turn.
- Keep cameras optional and give extra time to write; typing is slower than speaking.
- Run it at a time that is not the end of someone’s day in another time zone.
- Write the changes straight onto the board, so they exist before the call ends.

## A retrospective in Kanso

Open the [retrospective template](https://kansohq.app/templates/retrospective.md) in the project, fill it in together and turn each change into a card on the [board](https://kansohq.app/product/boards.md) with an owner and a due date. The next retro starts by opening the last one, so “last time’s changes” are the first thing on the page.

## Questions

### How often should a team hold a retrospective?

At the end of every sprint or release, or about every two to four weeks for teams that do not use sprints. A short, regular retro beats a long, rare one.

### How long should a retrospective be?

About an hour for a team of five to eight. Shorter for a small team, and no longer than ninety minutes for a large one.

### Who should run a retrospective?

Someone the team trusts to keep it blameless. Rotating the role keeps it fresh. A manager can take part, but should not judge what people say.

### What if the same problems keep coming up?

Then the changes are too big or have no owner. Pick one small change for the recurring problem, give it a name and a date, and check it at the next retro.

## Keep reading

- [How to write a blameless incident postmortem](https://kansohq.app/guides/how-to-write-a-postmortem.md): A blameless postmortem explains what broke, why and what changes. Learn the sections, how to write the timeline and root cause, and an example.
- [How to plan a sprint without overcommitting](https://kansohq.app/guides/how-to-plan-a-sprint.md): Sprint planning in five steps: set a goal, check capacity, choose work, break it down and name the risks. Includes how teams without sprints do it.
- [A software launch checklist, step by step](https://kansohq.app/guides/software-launch-checklist.md): A software launch checklist for product, quality and go-to-market, plus launch day and what to do after. Copy it, give every line an owner and ship.
- [Retrospective template for software teams | Kanso](https://kansohq.app/templates/retrospective.md): A retrospective template with what went well, what did not, what we learned and what we will change, each change with an owner. Copy it, or start it in Kanso.
- [Meeting notes template: decisions and actions | Kanso](https://kansohq.app/templates/meeting-notes.md): A meeting notes template that puts decisions first, then actions with owners and dates, then discussion and parked topics. Copy it, or start it in Kanso.

## Parts of Kanso used

- [Kanso Docs](https://kansohq.app/product/docs.md): Pages with headings, to-dos, tables and code, kept inside the project they describe, next to its board and its release.
- [Kanso Boards](https://kansohq.app/product/boards.md): A board for each piece of work. Cards carry a priority, an owner, a due date and the criteria that say when they are done.

[Kanso home, with plans and prices](https://kansohq.app/index.md)