What is a retrospective?meaning, examples, and how to run one

A retrospective is a team meeting to look back on recent work, discuss what went well and what could improve, and agree on what to change next. Teams often hold one after a sprint, project, or milestone. The goal is to leave with a specific improvement someone will put into practice.

The word retrospective means looking back. In agile teams, you may hear the meeting shortened to a retro. You do not need to use Scrum or work in software to run one.

Three questions to start a retrospective

• What went well? Look for practices worth repeating, such as pairing on a difficult task.
• What could have gone better? Describe a specific obstacle, such as waiting two days for a code review.
• What will we try next? Choose an action, give it an owner, and agree when to check the result.

You can use these prompts in the Classic Sprint retrospective template. Let everyone write their own answers before discussing them together.

Retrospective meaning in a team

A team retrospective is a learning meeting about the work itself. People examine decisions, handoffs, communication, tools, quality practices, workload, and trust while individual scores and rankings stay elsewhere.

A working definition can keep the scope clear.

A retrospective is a guided team conversation that uses evidence from a completed period to choose an improvement for the next period.

The completed period might be a two-week sprint, a release, an incident, a quarter, or an entire project. Any group can use the method to learn from shared experience. For a finite release, milestone, or cross-functional initiative, use the focused project retrospective guide.

How retrospectives differ from other meetings

Status meetings

Status reporting covers finished work, current work, and blockers. A retrospective digs into the reasons work moved or stalled, then asks the team to choose a response.

Sprint reviews

A sprint review examines the product with stakeholders and shapes future product work. A retrospective examines how the team worked and changes its process. Both can draw on evidence from the same sprint, though each meeting leads to a different decision.

Performance reviews

Performance reviews assess individuals. A retrospective keeps the discussion on observable events, systems, and team behavior because personal judgment makes people less likely to share uncertainty.

Postmortems

A postmortem usually investigates one failure or incident in depth. A retrospective can cover a wider period, including the practices that worked and the everyday friction that slowed people down.

Why teams run retrospectives

A useful handoff can grow into a bottleneck, a new tool can blur responsibilities, and a larger team may need different communication. Regular retrospectives give people a place to catch those shifts before the friction becomes routine.

• Continuous improvement: try a small change while the work is fresh. A large reorganization can wait.
• Shared ownership: let the people closest to the work diagnose the problem and shape the response.
• Earlier risk signals: bring quiet friction into the room before it hurts delivery or morale.
• Useful practices: name what worked so the team can repeat it deliberately.
• Follow-through: show participants that useful feedback leads to a visible action.

A practical retrospective example

Imagine a product team that keeps finding technical questions after sprint planning. "Improve tickets" is too broad to act on. During the retrospective, several cards point to the same problem. Engineers first see risky acceptance criteria once implementation has begun.

The team agrees to run one experiment. For the next two sprints, one engineer will join a 15-minute clarification before high-risk work enters planning. The action has an owner and a time limit, with fewer stories returning to refinement as the signal.

At the following retrospective, the team checks that signal and decides the experiment's next step.

Example action item: For the next two sprints, the engineering lead will arrange a 15-minute clarification of high-risk stories before planning. At the next retrospective, the team will check how many stories returned to refinement because requirements were unclear.

How to run a retrospective

If your group is new to the practice, the focused first retrospective guide has a short agenda and ground rules for beginners.

1. Check the previous action. Find out if the last experiment happened and what changed.
2. Name the scope. Tell everyone which sprint, release, project, or incident is up for discussion.
3. Write observations silently. Give each person time to contribute before confident voices steer the conversation.
4. Clarify and group the cards. Bring cards about the same pattern together while keeping meaningful disagreements visible.
5. Pick the priorities. Vote or agree on the one or two themes that deserve live discussion.
6. Look for causes and options. Ask which evidence supports the pattern and what conditions the team can change.
7. Choose an owned experiment. Record the action, its owner, the timing, and the signal you will check later.

A 30-minute retrospective agenda

Use this as a starting point for a small team discussing a familiar period of work. Invite the people who did the work and choose a facilitator to keep time and make space for everyone.

1. 0–5 minutes: Set the scene. Name the period you are reviewing, agree to discuss the work without blame, and check the previous action.
2. 5–10 minutes: Write notes. Each person answers what went well and what could improve, silently.
3. 10–15 minutes: Group and prioritize. Clarify the notes, group related observations, and choose one theme.
4. 15–25 minutes: Discuss the cause. Compare concrete examples and decide what the team can change.
5. 25–30 minutes: Agree on an action. Record one improvement, an owner, and a review date.

Allow more time for a larger group, a complex project, or a sensitive conversation. This agenda is a practical suggestion, not a Scrum rule: the Scrum Guide sets a maximum of three hours for a one-month Sprint, with shorter events for shorter Sprints.

Choose a format that matches the need

The prompts on a board steer what people notice. An online retrospective board can hold the team's notes, votes, and action items in one place. Browse the retrospective template library, or pick a format that fits the conversation in front of you:

• Classic Sprint works well for a team's first retrospective.
• Start Stop Continue leads to direct decisions about the process.
• Sailboat maps momentum, drag, risk, and the destination.
• Mad Sad Glad makes room for the emotional effect of the work.
• Safety Check helps when people seem hesitant or need clearer support.

Common retrospective mistakes

• Collecting fresh feedback before checking the previous action.
• Letting a manager or facilitator answer every prompt first.
• Discussing every card and leaving no time for the patterns.
• Writing vague actions such as "communicate better."
• Loading one cycle with too many improvements.
• Keeping the same format after it stops producing new evidence.