Purpose and scope
The Scrum Team inspects how the Sprint went in terms of people, relationships, process and tools. Specific issues that surface are identified, and ways of working are adapted. The Scrum Guide explicitly includes the Definition of Done as a candidate for inspection here.
The Sprint Retrospective concludes the Sprint and is scheduled after Sprint Review and before the next Sprint Planning, so its outputs can shape the next Sprint rather than sit in a document nobody revisits.
Who is involved
The entire Scrum Team participates, Product Owner included, since the Product Owner's collaboration style is also part of how the team works, not just what the team builds. The Scrum Master participates as a full team member and ensures the meeting is positive, productive, and stays within the timebox. There is no outside audience; this is an internal, often candid conversation.
Running a retrospective people actually want to attend
Vary the format. The same 'what went well, what didn't, what will we change' template every two weeks trains people to phone it in. Rotating structures, timelines, sailboat, start-stop-continue, or focusing each session on a single theme like meetings or handoffs, keeps the conversation fresh.
Limit the output. A retrospective that generates fifteen action items produces zero follow-through. Committing to one or two changes, owned by named people, with a plan to check on them next time, is what compounds over time.
Make it safe. If people believe raising a problem will be used against them, the retrospective becomes a performance where nothing real surfaces.
- Rotate the format so the exercise stays useful, not ritualistic
- Cap the improvement backlog to a small number of owned actions
- Revisit last retrospective's commitments before generating new ones
- Keep the conversation inside the team; this is not a stakeholder event
Anti-patterns
Skipping the retrospective when the Sprint was 'fine' is a common mistake; it is also where good Sprints get studied so their conditions can be repeated. Another failure is treating it as a venting session with no commitment to change, which teaches the team that raising issues is pointless.
A subtler anti-pattern is a Scrum Master or manager who dominates the conversation and proposes the fixes, rather than letting the team own its own diagnosis and remedy. Ownership is what makes the change stick.
How it connects to the rest of Scrum
Retrospective outcomes should visibly show up in the next Sprint's plan, whether as a change to how Sprint Planning is run, a tweak to the Definition of Done, or a new team working agreement. If Sprint Review is where the team inspects the product with stakeholders, the retrospective is where the team inspects itself alone.
Frequently asked questions
How is Sprint Retrospective different from Sprint Review?
Sprint Review inspects the product Increment with stakeholders and adjusts the Product Backlog. Sprint Retrospective inspects the team's own process, people and tools, with no outside stakeholders present, and adjusts how the team works.
Can the Definition of Done be changed in a retrospective?
Yes. The 2020 Scrum Guide explicitly lists the Definition of Done as something the Sprint Retrospective can examine and adapt, as long as any change still meets organizational standards where they exist.
How many action items should come out of a retrospective?
There is no rule in the Scrum Guide, but practically, one or two well-owned, concrete changes tend to actually get done, while long lists of action items rarely survive contact with the next Sprint.
Does the Product Owner attend the Sprint Retrospective?
Yes. The Product Owner is a full member of the Scrum Team, and the Scrum Guide includes them in the Sprint Retrospective along with the Scrum Master and Developers.