An agile retrospective is a recurring team meeting to examine how the work went and choose improvements to how the team works. It looks at collaboration, decisions, tools, quality, and workflow. Its practical output is an agreed change the team can try and review.
Gathering observations is the start. The harder work is deciding what they mean and which change is worth making.
In Scrum, the event has a specific name and purpose: the Sprint Retrospective. In other agile settings, teams can use retrospectives on an agreed cadence or after a meaningful period of work. This guide explains the distinctions and walks through an example from a vague complaint to a testable improvement.
Choose a board on the agile retrospective page, or follow our sprint retrospective agenda.
What an agile retrospective examines
A retrospective asks how the working system shaped the results: where work waited, how decisions were made, what helped quality, and whether previous improvements worked.
A missed delivery date is an observation, not yet an explanation. It might involve unclear scope, a dependency, unexpected technical work, insufficient capacity, or several of those things. “We need to work faster” skips that investigation and leaves the team without a usable change.
Examine successes too. If early discussion with support prevented a misunderstanding, identify what made that discussion possible so the team can preserve it.
Retrospective, sprint review, and postmortem: different questions
These conversations can share evidence, but they serve different purposes.
| Meeting | Main question | Typical participants | Useful output |
|---|---|---|---|
| Agile retrospective | How can we improve the way we work? | The team and relevant collaborators | A change to try and a way to inspect it |
| Scrum Sprint Review | What did we accomplish, what changed in the context, and what should happen next for the product? | Scrum Team and key stakeholders | Adaptations to future product work |
| Project postmortem | What can we learn from a completed project? | People involved in the project | Lessons and changes for future projects |
| Incident review | How did this incident happen, and how can we improve prevention, detection, or response? | Relevant operational and technical participants | System improvements and follow-up work |
Postmortem and incident-review practices vary between organizations; those rows describe common uses rather than a universal standard.
The Scrum Guide describes the Sprint Review as inspecting the outcome of the Sprint and determining future adaptations. It describes the Sprint Retrospective as planning ways to increase quality and effectiveness. A review is a working session with stakeholders, not merely a demonstration. A retrospective is not the place to turn every product decision into a second review.
Bring relevant incident-review findings to the retro to discuss follow-through, rather than repeating the investigation.
Who attends, and how long does it take?
For Scrum, the Scrum Team includes the Developers, Product Owner, and Scrum Master. The Product Owner belongs in the Sprint Retrospective because the event examines how the Scrum Team worked together. The Scrum Guide sets a maximum of three hours for a one-month Sprint and says the event is usually shorter for shorter Sprints. The Sprint Retrospective concludes the Sprint.
That maximum is not a recommendation to fill three hours. A 45-minute agenda can suit a focused discussion; it is not an official Scrum requirement. Allow enough time to understand observations and make an improvement decision within the applicable timebox.
For teams using continuous flow, there is no Sprint boundary to supply the cadence. An explicit agreement is useful: for example, meet every two weeks, inspect items completed and still waiting during that period, and revisit the previous experiment. That is a practical starting recommendation, not a Kanban rule. Adjust it when the pace of work or the time needed to observe a change calls for a different interval.
Invite a collaborator when their knowledge is needed, while considering how their presence affects candor. An outside dependency owner may help with one topic without needing to attend every discussion. A manager should not use the meeting to rate individuals.
A worked example: from “reviews are slow” to an experiment
The following scenario is illustrative. The numbers and proposed changes show the reasoning; they are not a report of a customer outcome.
Imagine a recurring card: “Code reviews take too long.” The response, “Please review faster,” changes nothing because neither problem nor behavior is specific.
1. Describe the observation
The team examines five recent review requests. Three remained unstarted until the author asked about them in a chat. Two began without a reminder. Reviewers say they sometimes cannot tell whether a request is ready for their attention or which reviewer should take it.
Check missing context: request size, arrival time, and competing incidents. These cases do not prove that all reviews are slow or reviewers lack motivation.
2. Write a hypothesis that could be wrong
The team proposes:
Some review requests wait because readiness and ownership are unclear. Naming a reviewer and including the context needed to begin might reduce the need for the author to chase.
If review capacity is the real constraint, changing the request format may not help.
3. Agree on a small experiment
For the next sprint, try the change on the next five eligible review requests. “Eligible” means ready for review, with checks complete and no known unresolved author work. Each request includes:
- A named reviewer who has agreed to take it, or an explicit request to find one.
- A short description of the change and the question the author wants reviewed.
- Relevant test or reproduction steps.
One team member arranges the trial and keeps the record. The team agrees how to flag an absent reviewer and how urgent requests fit the process. Do not silently add a new obligation to a colleague who was not part of the agreement.
4. Decide what evidence to check
At the next retro, inspect the eligible requests. Did a reviewer begin without an author reminder? Did they still need to ask for basic context? Were requests left waiting despite a named reviewer? Did the extra preparation create avoidable work for authors?
Note different request sizes and interruptions. Five cases can suggest whether the practice is promising, not establish a universal causal result.
5. Keep, adapt, or stop
If the trial helped, keep the useful parts. If requests still waited because nobody had review capacity, adapt the hypothesis and examine capacity. If the checklist added effort without helping reviewers begin, simplify it or stop it.
The owner coordinates the experiment. Learning that the explanation was wrong is still useful.
Use a Went Well, To Improve, Action Items board for the observations and agreement, or Start, Stop, Continue to discuss the practice after the trial. The action items guide covers the follow-up record in more detail.
Ask questions that match the team's actual problem
A different format cannot compensate for a question that is too vague. Use prompts that locate an event or decision people can examine.
| Pattern you notice | Ask this | Look for |
|---|---|---|
| Work repeatedly waits | “Which item waited, where, and what was needed for it to move?” | A queue, dependency, or missing signal |
| Scope changes cause rework | “What did we learn late, and who could have helped us learn it earlier?” | An information gap or delayed decision |
| Priorities compete | “Which two requests could not both fit, and how did we choose?” | An unclear trade-off or decision owner |
| Quality problems recur | “What made this problem hard to prevent or detect?” | A gap in feedback, checking, or working conditions |
| A helpful practice disappears | “When did this work well, and what conditions made it possible?” | A behavior or resource worth preserving |
| The same action returns | “What happened between agreeing on it and trying it?” | A blocker in ownership, authority, or capacity |
Ask “Can you show a recent example?” If details cannot be shared publicly, agree on another way to investigate.
Separate evidence from blame
Evidence can include ticket history, decisions, review requests, customer feedback, and participants' accounts of their experience. Feelings matter: “I felt unable to raise the risk” is relevant evidence about that person's experience. It is not proof that another person intended to silence them.
Distinguish three things in the discussion: what happened, what someone inferred, and what remains unknown. “The request had no reviewer” is an observation. “Nobody cared” is an interpretation. The next question is what prevented a reviewer being identified, not who deserves the most criticism.
Blameless facilitation does not mean ignoring responsibility or avoiding difficult facts. It means examining decisions in the context of what people knew and the constraints they faced. Serious conduct concerns may need a separate, appropriate reporting process; a group retro should not be used to investigate them through public accusation.
For that facilitation approach, read what a blameless retrospective means.
When a game helps, and when to use plain language
A metaphor can help people notice something they have overlooked. A Sailboat retrospective, for example, can distinguish forces helping progress from anchors holding it back. Our fun retro activities offer work-focused exercises with debrief questions.
Use plain prompts when a team is processing a serious incident, conflict, burnout, or unwelcome organizational change. Also drop a theme when it adds explanation without improving the discussion. Participants should be able to write a sentence, use text instead of drawing, or pass without defending that choice.
The test is whether the activity makes the work easier to examine. Novelty and laughter are optional.
Signs the improvement loop is not working
Watch for these patterns:
- The same complaint appears repeatedly: Check whether the previous action was tried before inventing another one.
- Every action belongs to “the team”: Name who will arrange the first step and confirm their agreement.
- Actions need absent people to comply: Record the dependency request rather than an assumed commitment.
- The action is “communicate better”: Identify a specific decision, handoff, or missing piece of context.
- The board fills with actions nobody has capacity to try: Choose a smaller experiment or explicitly make room for it.
- An action is declared complete because a document was written: Check whether the practice affected the work it was meant to improve.
Review the previous change before opening fresh promises. When nothing was tried, examine why: that is evidence about the team's ability to improve.
Frequently asked questions
What is the purpose of an agile retrospective?
An agile retrospective helps a team examine how it works and agree on improvements. It considers collaboration, decisions, tools, workflow, and quality. A useful outcome is a change the team can try, with an owner, evidence to inspect, and a review date.
Is an agile retrospective the same as a sprint retrospective?
A sprint retrospective is a specific Scrum event at the end of a Sprint. Agile retrospective is a broader term for a team improvement conversation that can also be used outside Scrum. Teams without Sprints can agree on a cadence suited to their work and revisit their improvement experiments regularly.
Who attends a Scrum Sprint Retrospective?
The Scrum Team participates, including Developers, the Product Owner, and the Scrum Master. The conversation examines how the Scrum Team worked together. Invite other collaborators selectively when their contribution is needed, while considering candor and the focus of the event.
What is the timebox for a Sprint Retrospective?
The Scrum Guide sets a maximum of three hours for a one-month Sprint and says the event is usually shorter for shorter Sprints. The maximum does not mean every team should use all of that time. Plan a focused discussion that fits the applicable timebox.
What is the difference between a sprint review and a retrospective?
A Sprint Review inspects the Sprint's outcome with key stakeholders and considers future product adaptations. A Sprint Retrospective examines how the Scrum Team worked and plans improvements to quality and effectiveness. They can use some of the same evidence but make different kinds of decisions.
What should a team do after a retrospective?
Try the agreed improvement, keep enough evidence to inspect what happened, and review it at the next retrospective or agreed date. Decide whether to keep, adapt, or stop the change. If it was not tried, examine the blocker before adding another action.