Sprint Retrospective: Ideas, Agenda & Format [2026]
A. Togay Koralturk, Best-Selling PMP Author
Last updated on August 23, 2026
12 min read
A team that never asks itself "how are we actually working?" will repeat the same mistakes sprint after sprint, only faster. The sprint retrospective is Scrum's deliberate pause to prevent exactly that — the one meeting aimed not at the product but at the team itself. Skipped or run as a blame session, it's the first ceremony teams drop; run well, it's the quiet reason good teams keep getting better. This guide explains the sprint retrospective in full — its purpose, who attends, the timebox, the five stages, retrospective ideas and formats to keep it fresh, and how it appears on the PMP and CAPM exams.
What is a sprint retrospective?
A sprint retrospective is the final event of each sprint, where the Scrum team reflects on how the sprint went and decides on concrete ways to improve. It comes right after the sprint review and closes the sprint, turning the team's attention from what it built to how it worked together to build it.
The retrospective is Scrum's built-in mechanism for continuous improvement. Instead of letting friction, inefficiency, and small frustrations accumulate sprint after sprint, the team pauses to examine its own process — the interactions, tools, and habits that shaped the last two weeks — and picks a few things to change. Its focus is deliberately inward: not the increment or the backlog, but the team and the way it works. A good retrospective ends not with a discussion but with a short list of improvements the team genuinely intends to act on.
The purpose of a sprint retrospective
The purpose of a sprint retrospective is to inspect how the last sprint went — across people, relationships, process, and tools — and to plan improvements that make the next sprint better. It exists to convert the team's lived experience into deliberate change, so the same problems don't quietly repeat.
Three things give the retrospective its value. First, it drives continuous improvement: small, regular adjustments compound into a markedly more effective team over time, the same kaizen thinking at the heart of lean project management. Second, it creates a safe space to be honest: because it is the team's own meeting, people can raise what isn't working without it becoming a performance review. Third, it produces ownership of change: the improvements come from the team itself, so they are far more likely to stick than fixes imposed from outside. Remove any of these — no honesty, no follow-through, or no real change — and the meeting becomes a hollow ritual. The retrospective earns its place only when reflection reliably turns into action.
Ready to take the next step in project management?
200,000+ Learners Trust Our Instructors
When is it held and how long?
The sprint retrospective is held at the very end of the sprint, after the sprint review, as the last event before the next sprint begins. This ordering is intentional: the review gathers outside feedback on the product first, and the retrospective then lets the team reflect privately on how it worked, informed by everything the sprint surfaced.
It is timeboxed to a maximum of three hours for a one-month sprint, and proportionally less for shorter sprints — around 90 minutes for a two-week sprint, and often under an hour for a one-week one. As with every Scrum timebox, this is a ceiling rather than a target. The length matters less than the rhythm: holding a retrospective every sprint, without fail, is what makes the improvement loop work. Teams that treat it as optional and skip it "just this once" when things are busy are usually the teams that most need it.
Who attends the sprint retrospective?
The sprint retrospective is for the Scrum team only: the developers, the product owner, and the Scrum Master, who facilitates. Unlike the outward-facing sprint review, this is a deliberately private meeting — and that privacy is not incidental, it is the point.
Keeping outside managers and stakeholders out of the retrospective is what makes people candid. If a functional manager is in the room, team members hedge, blame gets political, and the honest conversation the meeting depends on simply doesn't happen. The retrospective works because it is a space where the team can admit mistakes, name friction, and disagree openly without an audience to perform for. The Scrum Master's job is to facilitate that safety — often opening with the retrospective prime directive: a reminder that everyone did the best they could with what they knew at the time. Protect the room, and the honesty follows; open it up to observers, and the retrospective quietly dies.
The five stages of a retrospective
The most widely used structure for a retrospective comes from Esther Derby and Diana Larsen's book Agile Retrospectives, which breaks the meeting into five stages. Following them keeps a retrospective from drifting into an unfocused gripe session and steers it toward action.
- Set the stage. Open the meeting, make it feel safe, and get everyone present and engaged — often with the prime directive and a quick check-in so people are ready to speak.
- Gather data. Build a shared picture of what actually happened during the sprint: the facts, the events, and how people felt about them. This is about recall, not judgment yet.
- Generate insights. Dig into why — look for patterns, root causes, and the forces behind what went well and what didn't. The team moves from "what happened" to "what it means."
- Decide what to do. Choose a small number of concrete, actionable improvements, each with an owner. A few changes the team will actually make beat a long list it won't.
- Close. Wrap up: confirm the action items, appreciate the team's contributions, and briefly reflect on the retrospective itself so it, too, keeps improving.
The arc runs from opening up, to understanding, to committing — and the fourth stage is where most retrospectives succeed or fail. A meeting that stops at "generate insights" produces good conversation and no change; the discipline is in always reaching a few owned actions.
Sprint retrospective ideas and techniques
Running the same format every sprint is the fastest way to make a retrospective stale, so teams rotate through different techniques to keep the reflection fresh and surface different kinds of insight. Each of the formats below is a different lens on the same five-stage arc — mostly ways to run the "gather data" and "generate insights" stages.
| Technique | How it works |
|---|---|
| Start, Stop, Continue | The team lists what it should start doing, stop doing, and keep doing. Simple, action-oriented, and a great default. |
| Mad, Sad, Glad | Members sort the sprint's events by how they felt about them, surfacing the emotional signals a purely factual review misses. |
| 4 Ls | Liked, Learned, Lacked, and Longed for — a balanced prompt that captures wins, learning, and gaps in one pass. |
| Sailboat | The team maps what pushed it forward (wind) and what held it back (anchors), a visual metaphor that makes obstacles easy to name. |
| DAKI | Drop, Add, Keep, Improve — focuses directly on concrete changes to the team's practices. |
| Rose, Thorn, Bud | Roses (positives), thorns (problems), and buds (opportunities) — quick to run and good for mixed experience levels. |
There is no single "best" technique; the right one depends on the team's mood and what the sprint threw at it. The value of rotating is partly the different questions each format asks and partly the simple fact that variety keeps people engaged. Whatever the format, the ending is always the same: a few actionable improvements the team commits to.
Sprint review vs. retrospective
The sprint retrospective is constantly confused with the sprint review, because the two events sit back to back at the end of the sprint. The distinction is simple once you anchor on their focus: the review is about the product, the retrospective is about the team.
| Sprint review | Sprint retrospective | |
|---|---|---|
| Focus | The product and the increment | The team's process and collaboration |
| Question it answers | Are we building the right thing? | How can we work better? |
| Who attends | Scrum team + stakeholders | The Scrum team only |
| Main output | An adapted product backlog | A few owned process improvements |
| When | Near the end of the sprint | After the review, closing the sprint |
The review looks outward and gathers stakeholder feedback to steer what gets built; the retrospective looks inward and gathers the team's own reflection to improve how it gets built. Both are inspect-and-adapt events, but confusing them — for example, letting stakeholders into the retrospective, or skipping process improvement because "we covered feedback in the review" — undermines both. Keep them separate and each does its job.
Best practices and anti-patterns
Retrospectives fail quietly and predictably. A few habits keep them alive and useful:
- Produce a few owned actions, not a long list. Pick one to three improvements the team will actually make, each with an owner, and add at least one to the next sprint's work so it doesn't evaporate.
- Follow through — and check last time's actions first. Start each retrospective by reviewing whether the previous actions happened. Nothing kills a retrospective faster than a team learning its decisions never matter.
- Protect psychological safety. Open with the prime directive, keep managers out, and treat the meeting as blameless. Candor is the fuel; remove it and the meeting runs dry.
- Vary the format. Rotate techniques to keep engagement up and surface different insights, rather than reciting the same three questions every fortnight.
- Never skip it. Holding the retrospective every sprint, especially the busy ones, is what makes the improvement compound.
The defining anti-pattern is the retrospective that changes nothing: the team meets, vents, lists the same problems as last time, and disperses. When action items are never completed, the recurring issues aren't a data problem — they're a follow-through problem, and the fix is owned, tracked improvements, not more discussion.
Sprint Retrospective on the PMP® and CAPM® Exams
Because the current PMP exam emphasizes agile delivery and, throughout, continuous improvement, the retrospective is a natural exam topic — and it maps onto the traditional idea of lessons learned, applied every sprint rather than only at project close. The facts to lock in: it is the last event of the sprint, timeboxed, attended by the team alone, and focused on improving the team's process with concrete, owned actions.
Situational questions tend to probe whether you understand why the retrospective is structured as it is: they describe a manager wanting to attend, a team that never follows through, or a blame-heavy session, and reward the answer that protects psychological safety and turns reflection into owned improvements. Watch for the trap of confusing it with the review — the retrospective is process and team, not product and stakeholders. The project manager's role is servant-leader facilitation, not judgment. Our PMP Complete Study Guide, the most complete on the market, covers continuous improvement and the agile events the exam expects you to apply.
PMP Practice Question: Sprint Retrospective
A sprint ends with its goal clearly missed, and the sponsor, wanting to understand what went wrong, asks to sit in on the team's sprint retrospective and requests that its notes be circulated to management afterward. Several team members privately tell the Scrum Master they will keep quiet if that happens. The retrospective is scheduled for tomorrow.
What should the Scrum Master do?
a) Welcome the sponsor, since Scrum is built on transparency and leadership visibility will help the improvement actions get organizational support.
b) Hold the retrospective with the Scrum team only, and meet the sponsor's need by sharing the sprint's outcomes and the resulting improvement actions through the appropriate channel instead.
c) Postpone the retrospective to the next sprint, when the tension around the missed goal has cooled and the discussion can be more objective.
d) Invite the sponsor to this retrospective only, since a failed sprint is exactly when stakeholders deserve direct answers, and return to team-only sessions afterward.
Correct answer: B.
Rationale: The retrospective is the Scrum team's internal inspection of its own process, and its working condition is candor — the team members have already said, plainly, that an audience will silence them, which would leave the sponsor observing a meeting whose content just walked out the door. The sponsor's underlying need is legitimate and answerable: what happened, and what will change, both of which the team can share as outcomes and committed improvement actions without exposing the raw discussion. Choice a) confuses transparency of results with surveillance of the conversation that produces them; choice d) is the more tempting version of the same mistake, because a one-time exception after a failed sprint teaches the team that bad sprints bring observers, sanitizing exactly the retrospectives that matter most; choice c) delays Scrum's improvement mechanism at the moment it has the most to inspect, and the tension it avoids is the signal, not the obstacle. To face more questions where competing goods collide like this, work through our PMP practice exams or, at the entry level, our CAPM practice exams.
Ready to take the next step in project management?
200,000+ Learners Trust Our Instructors
Frequently asked questions
What is a sprint retrospective?
A sprint retrospective is the last event of each sprint, where the Scrum team reflects on how the sprint went — across its people, process, and tools — and decides on a few concrete improvements to make. It comes right after the sprint review and closes the sprint. Its focus is the team's own way of working, not the product, and it is Scrum's engine of continuous improvement.
What is the purpose of the sprint retrospective?
The purpose is to inspect how the last sprint went and plan improvements that make the next one better. It converts the team's experience into deliberate change through continuous improvement, an honest and safe space to discuss what isn't working, and team ownership of the fixes. A retrospective succeeds only when its reflection reliably turns into acted-on change.
Who attends the sprint retrospective?
The Scrum team only: the developers, the product owner, and the Scrum Master, who facilitates. Outside managers and stakeholders are deliberately not invited, because their presence makes team members less candid. That privacy is what allows the honest, blameless conversation the retrospective depends on to actually happen.
When is a sprint retrospective held and how long is it?
The sprint retrospective is held at the very end of the sprint, after the sprint review and before the next sprint starts. It is timeboxed to a maximum of three hours for a one-month sprint, and proportionally less for shorter sprints — around 90 minutes for a two-week sprint. The timebox is a ceiling, and holding it every sprint matters more than its exact length.
What is the difference between a sprint review and a sprint retrospective?
The sprint review focuses on the product: the team and stakeholders inspect the increment and adapt the product backlog. The sprint retrospective focuses on the team's process: the Scrum team alone reflects on how it worked and picks improvements. The review includes stakeholders and looks outward; the retrospective is internal and looks inward. The review comes first, then the retrospective closes the sprint.
What are some good sprint retrospective ideas?
Popular formats include Start-Stop-Continue, Mad-Sad-Glad, the 4 Ls (Liked, Learned, Lacked, Longed for), the Sailboat (wind versus anchors), DAKI (Drop, Add, Keep, Improve), and Rose-Thorn-Bud. Each is a different lens on the same reflection, and teams rotate through them to keep the meeting fresh and surface different insights. Whatever the format, the retrospective should still end in a few owned, actionable improvements.
Is the sprint retrospective on the PMP exam?
Yes. The current PMP exam covers agile approaches heavily and emphasizes continuous improvement, so the retrospective appears in scenario questions and maps onto the idea of lessons learned. You are expected to know it is a team-only event focused on improving the process, and to recognize what protects it — psychological safety and owned, followed-through actions.
Is the sprint retrospective on the CAPM exam?
Yes. The CAPM covers the Scrum events, including the retrospective, usually a little more directly than the PMP — often testing its purpose, who attends, the timebox, or how it differs from the review. Because the CAPM is scenario-based, you should also be ready to spot a retrospective being run poorly, such as one with a manager present or one that never produces change.
What Is Scrum? Roles, Events & Artifacts [2026]
Scrum is a lightweight agile framework for complex work. Its theory, the 3 roles, 5 events, and 3 artifacts, scrum vs. agile, benefits, and PMP exam tips.
Scrum Master: Role, Responsibilities & Skills [2026]
A scrum master is a servant leader who helps a team work effectively. Responsibilities, scrum master vs. project manager, skills, becoming one, and exam tips.
Product Owner: Role, Responsibilities & Skills [2026]
The product owner maximizes a product's value and owns the backlog. Responsibilities, product owner vs. scrum master, skills, how to become one, and exam tips.
