Flocci Projects

HomeAgile answers › What is a sprint retrospective and how do I run one?

What is a sprint retrospective and how do I run one?

A retrospective is a short meeting at the end of each sprint where the team inspects how it worked and picks improvements. The format matters less than the output: one or two concrete changes with an owner. A retrospective that produces a list of feelings and no action is theatre.

The minimum viable retro

Thirty minutes, three questions: what went well, what did not, what will we change. Everyone writes silently first — otherwise the first speaker anchors the room — then group the themes and vote. Pick at most two changes, because a team that commits to six changes makes zero.

Bring data, not just memory

Open the velocity trend and the status distribution before the discussion. 'Velocity dropped from 22 to 13' is a better starting point than 'the sprint felt bad', and the workload chart often explains it — one person carrying half the sprint is a process problem, not a personality one.

The follow-through rule

Each change gets an owner and appears in the next retrospective as the first agenda item: did it happen, did it help. Without that loop, retrospectives decay into a complaint ritual and attendance becomes reluctant within a quarter.

Safety is a precondition

People only name real problems when doing so is safe. If the team's honest answer to 'what went badly' is a manager's decision, and nobody says it, the meeting cannot work. Start with process, earn trust, and let the harder topics arrive on their own.

Try it on a free Flocci Projects board

Related questions

How often should we hold retrospectives?

Every sprint, at the end. Monthly retrospectives on a two-week cadence lose the detail that makes them useful, because by then nobody remembers why the sprint went sideways.

What if the same problem comes up every time?

That is the most valuable signal in the room: it means the problem is outside the team's control or the agreed fix never happened. Escalate it explicitly rather than re-discussing it a fourth time.

Should we retro a successful sprint?

Yes — success is when you can identify what worked and make it deliberate. Skipping retros after good sprints means you only ever learn from failure, which is a slow and expensive curriculum.

More agile answers