Start free demo →
M
Melororium
Project Management4 min read

What is a Retrospective?

A retrospective is a structured team meeting at the end of a sprint or project to review what went well, what didn't, and what to change next time.

A retrospective (or retro) is a structured team meeting that happens at the end of a sprint or project. Its purpose is to review how the team worked together — not what was built, but how the building process went — and agree on one or two specific improvements for next time.

Retrospectives come from Scrum, where they're one of the five ceremonies. But the practice is useful for any team working in cycles: monthly reviews, end-of-project reviews, quarterly team health checks all follow the same basic structure.

The key word is "structured." An unstructured "how did that go?" conversation tends to produce vague feedback and no commitments. A structured retrospective produces specific, actionable changes that the team actually implements.

Common Retrospective Formats

Several formats work well. The most widely used is "Start, Stop, Continue":

  • Start, Stop, Continuewhat should we start doing? what should we stop doing? what's working and should continue?
  • What Went Well / What Didn't / Actionssimple three-column format, great for teams new to retros
  • 4Ls: Liked, Learned, Lacked, Longed Foradds nuance around learning and unmet needs
  • Sailboatwhat's propelling us forward (wind)? what's holding us back (anchors)? what's the goal (island)? what are the risks (rocks)?
  • Mad, Sad, Glademotional temperature check, useful when team morale is a concern

How to Run a Retrospective

A 60-minute retrospective for a team of 4–8 follows this structure:

5 min: Set the context — review the sprint/project goal and whether it was achieved. 20 min: Gather data — each person writes items for each category on sticky notes (physical or digital). 10 min: Group themes — cluster related items together, identify patterns. 15 min: Prioritize and discuss — vote on the top 2–3 issues to address. 10 min: Action items — for each issue, define a specific action, assign an owner, and set a due date.

The action items are the output of the retrospective. Without them, a retro is just a venting session.

FormatTimeBest for
Start/Stop/Continue45 minRegular sprint retros
What Went Well/Didn't/Actions45 minTeams new to retros
Sailboat60 minProject-level reviews
4Ls60 minTeams focused on learning

Why Retrospectives Fail

Most retrospective failures come from one of four causes:

No psychological safety — team members don't feel safe raising real issues, so everyone says "it was fine." Managers can fix this by sharing their own candid observations first.

No action items — the team identifies problems but doesn't commit to changes. Without specific actions and owners, nothing improves.

Actions never reviewed — action items from last retro aren't checked at the start of the next one. Teams quickly learn that retro actions don't matter.

Running retros when nothing can change — if the team raises the same issues every retro and nothing improves, they'll stop engaging. Retros are only worth running when the team has the authority to actually change something.

Retrospective for a 6-Person Team: Real Transcript

This is a lightly edited transcript from a 45-minute retrospective with a 6-person agency team after a 6-week website project.

What went well: 'The Figma handoff to development was the smoothest we've done. The design spec was complete before development started — that saved at least 8 hours of back-and-forth.' 'Weekly client updates worked. No surprise feedback at launch.'

What didn't go well: 'Content was the bottleneck every time. We waited 11 days for homepage copy. It pushed the dev timeline by a full week.' 'Three people edited the staging site simultaneously during testing. Two of them overwrote each other's changes. We lost 4 hours recovering.' 'The kickoff meeting ran 90 minutes with no agenda.'

Action items: Action 1: Add a content deadline to every project contract with a clause — if content arrives more than 5 business days late, the project timeline shifts accordingly. Owner: account manager. Done by: next project kickoff. Action 2: Staging environment access goes to one person at a time during testing phases. Owner: tech lead. Done by: this Friday. Action 3: Kickoff agenda sent to client 48 hours before the meeting. Owner: project manager.

  • Specific problems lead to specific actionsvague observations lead to nothing
  • Three actions maximumeight action items mean zero action items
  • Every action has one owner and a deadline within 2 weeks

Action Items from Retrospectives: How to Make Them Stick

Most retrospective action items die within a week. The retrospective felt productive, but nothing changed. It's a predictable failure with predictable causes.

Why action items die: they're vague ('communicate better'), they have no single owner, there's no deadline, and there's no follow-up mechanism.

What works:

One sentence, verb-first. 'Send kickoff agenda to client 48 hours before every meeting' — not 'improve the kickoff process.' The verb-first format describes a specific behavior change.

One named owner. Not 'the team.' One person who is responsible for the action happening.

A deadline within 2 weeks. Actions due 'next quarter' don't happen.

Three actions per retrospective maximum. Twelve actions means the team knows none of them will happen.

Carry-forward check. Start every retrospective by reviewing the previous one's action items. Done? Close it. Not done? Why not?

Put actions in your task tracker. A retrospective action item that lives only in meeting notes doesn't exist.

  • Verb-first, single sentenceif you can't write it that way, the action isn't specific enough
  • Single owner'the team' is no one
  • 3 actions per retrospectivechoosing 3 forces prioritization
  • Carry-forward check at the start of every retrospectivebefore adding new items

Remote Retrospectives: Making Them Work

Remote retrospectives fail for the same reasons all remote meetings fail: low engagement, awkward silences, and one or two people filling the space while others go quiet.

Async input before the call. Share a simple prompt 24 hours before: 'Add your went-well and didn't-go-well items to this doc before the call.' When the meeting starts, you're discussing ideas, not generating them. This means quieter team members contribute before the social dynamics of the call shape who speaks.

Camera on. This is not optional for a retrospective. Reading expression matters in a conversation about what's working and what isn't.

Named facilitator. In a physical room, someone leads naturally. Remotely, without a clear facilitator, conversations stall. Rotate the role every retrospective so it doesn't default to the manager.

Screen-shared action items. Share your screen and type action items in real time while the team watches. Everyone sees what's being captured.

Maximum 60 minutes. Remote attention spans are shorter than in-person. A tight 60-minute retrospective gets more done than a meandering 90-minute one.

  • Async input 24 hours before the callquiet team members contribute before social dynamics kick in
  • Camera on for retrospectivesexpression matters in this conversation specifically
  • Rotate the facilitator rolethe manager as default facilitator changes what people say
  • 60 minutes maximumset the timer and stick to it

Melororium

Review team output in Melororium Work Reports

Project management, time tracking, CRM, and invoicing — one flat monthly fee. Starter $29/mo · Agency $59/mo · Studio $119/mo.

Frequently Asked Questions

How long should a retrospective be?

45–90 minutes for a sprint retrospective. Less than 45 and there's no time for meaningful discussion. More than 90 and attention drops. For an end-of-project retrospective covering a 3-month project, 2 hours with a break is appropriate.

Who should attend a retrospective?

The entire team doing the work — developers, designers, project managers, anyone who was actively part of the sprint. The Product Owner attends in Scrum. Clients and senior management generally don't attend, as their presence changes the team dynamic.

How do you make retrospectives more effective?

Start by reviewing action items from the last retrospective. Use a structured format with voting to prioritize. End with no more than 3 specific action items with owners and due dates. Rotate the facilitator role so it doesn't feel like a manager's meeting.

Put it into practice

Manage it all in Melororium

Project management, time tracking, CRM, and invoicing — one workspace, one flat fee. From $29/mo.