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.
What it inspects is not the product. Every other event in Scrum points at what the team is building, and this one points at how the team builds it.
What is on the table
The Scrum Team looks at how the last Sprint went with regard to individuals, interactions, processes, tools and its Definition of Done. The last of those is the item teams most often skip and the one most likely to produce a lasting change, because the Definition of Done sets the standard for everything the team ships. Tightening it changes every future Sprint rather than only the next one.
The other four cover ground a delivery conversation never reaches. How people worked together, where the handovers stalled, which tool cost an afternoon and which agreement nobody kept are all legitimate material here and nowhere else in the framework.
The output is a change, not a list
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 is what 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
The whole Scrum Team attends, meaning the Developers, the Scrum Master and the Product Owner. The Product Owner is a member of the team rather than a visitor, and a Product Owner who treats the event as somebody else's meeting removes half of what makes a Sprint work from the conversation.
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 facilitating the event is a service rather than 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, the whole literature of starfish diagrams and sailboats and what went well, is technique rather than framework.
The Guide also does not say the Scrum Master must facilitate. It is the usual arrangement and a sensible one, and a team that rotates facilitation or invites somebody from outside to run it is not breaking a rule.
The failure worth recognising
The most common is the retrospective that has become a ritual. It happens every Sprint, surfaces the same handful of observations, changes nothing anyone can point to, and eventually 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 second is the session that only produces demands of other people. Some impediments genuinely are external and removing those is part of the Scrum Master's service, and a team whose retrospective never finds anything within its own control has stopped inspecting itself.