The Sprint Retrospective is the event in which the Scrum Team inspects itself. It concludes the Sprint, follows the Sprint Review and is timeboxed to a maximum of three hours for a one month Sprint.
The subject of that inspection is the team and never the product. Every other event in Scrum points at what the team is building, and this one points at how the team builds it, so it comes after the Sprint Review and has the Review's evidence to work from.
What the Scrum Team inspects
The Scrum Team inspects how the last Sprint went, covering the people in it, their interactions, the processes they used, their tools and their Definition of Done. The Definition of Done is the item teams most often skip, and it is the one most likely to produce a lasting change, because it sets the standard for everything the team ships. Tightening it changes every future Sprint, since the new standard applies to every Increment after it.
The people, their interactions, the processes and the tools reach material a delivery conversation never touches, such as how people worked together, which handover stalled, which tool cost an afternoon and which agreement nobody kept. No other event in Scrum has room for any of it.
The output of the Sprint Retrospective
The Scrum Team identifies the most helpful changes to improve its effectiveness, and the most impactful improvement may be added to the Sprint Backlog for the next Sprint. Putting it there separates a retrospective from a discussion, because an improvement that lives anywhere else competes with delivery work for attention and loses.
A retrospective that produces fifteen observations and no owned change has produced nothing at all. One change the team actually makes is worth more than a list nobody opens again.
Who takes part in the Sprint Retrospective
The whole Scrum Team attends, meaning the Developers, the Scrum Master and the Product Owner. The Product Owner is a member of the team, so a Product Owner who treats the event as somebody else's meeting takes half of what makes a Sprint work out of the conversation. How items arrive, how refinement happens and how the Sprint Goal was formed are all part of how the team works.
Managers and stakeholders are not participants. Their presence changes what people are willing to say, and a retrospective in which nobody will name the real impediment has spent three hours on the safe ones. The Scrum Master takes part as a member of the team, and the role of facilitator is a service to the event and never ownership of it.
What the framework deliberately leaves open
Scrum names no format. There is no required set of questions, no obligatory timeline exercise, no rule about voting and no prescribed number of actions. Everything written about how to run one, which includes the whole literature of starfish diagrams and sailboats and what went well, is technique, and a team is free to use any of it or none.
The Guide also never says the Scrum Master has to run the event. That arrangement is the usual one and a sensible one, and a team that rotates the facilitator or invites somebody from outside is not breaking a rule.
The failures worth recognising
The commonest failure is the retrospective that has become a ritual. It happens every Sprint, surfaces the same handful of observations and changes nothing anyone can point to, until the team asks whether it could be dropped. The answer in Scrum is not to cancel the event, because the complaint is a symptom of output that never reached the Sprint Backlog and never became work.
The other failure is the session that only produces demands of other people. Some impediments genuinely are external, and causing their removal is part of the Scrum Master's service, so naming them is right. If a team's retrospective never finds anything within its own control, the team has stopped inspecting itself.