Retrospectives and Intraspectives

Sprint Retrospective — an event that occurs at the end of the sprint to reflect on how things went and look for improvements. It's facilitated by the Scrum Master, attended by the development team (the product owner is optional), and timeboxed to a maximum of roughly three hours for a month-long sprint (shorter for shorter sprints). The focus is self-inspection and adaptation, and the outcome is an improvement implementation plan for the next sprint — improvement items are typically added to the backlog as non-functional stories, so they compete for priority like any other work rather than being a vague promise nobody tracks.

The retrospective covers what went right and should be kept, what didn't go so well across process, tools, people, and relationships, how to improve on the shortcomings, and agreement on concrete action items for the next sprint.

Esther Derby and Diana Larsen's five-step structure is the standard way to run one: Set the Stage (create safety, frame the session), Gather the Data (build a shared, factual picture of what happened), Generate Insights (ask why — this is where Fishbone or 5-Why often gets used), Decide What to Do (commit to specific, actionable improvements), and Close the Retrospective (summarize, appreciate, and formally end the session).

Retrospective vs. Sprint Review — these get confused constantly. A retrospective is primarily for the development team, and its purpose is improvement of process, technique, or anything else the team controls. A sprint review's participants include the team, product owner, scrum master, customer, and other stakeholders, and its purpose is demonstrating completed work to the customer/PO and getting acceptance of the deliverables — it's about the product, not the team's internal process.

Retrospective vs. Lessons Learned — a retrospective is a regular meeting that happens at the end of every iteration, aimed at improving the very next iteration within the same project. A lessons-learned session happens once, at the end of the whole project, and its documented improvements are meant to benefit other, future projects — not this one, which is already over.

Intraspective — an ad-hoc meeting called in when something wrong is observed, rather than waiting for the scheduled end-of-sprint retrospective. "Intra" means inside/within, "(per)spective" means a viewpoint on something — an intraspective is the team looking inward, right now, at a problem that just happened. It's triggered by something that didn't go well or a behavior that needs correcting, and its purpose is to inspect current practices and decide on changes immediately, without waiting. The Scrum Master, acting as the team's conscience, is often the one who calls it when the team isn't living up to its own agreed values.

Study focus: the single differentiator PMI tests between a retrospective and an intraspective is timing — retrospective is planned, happens at the end of the iteration; intraspective is ad-hoc, happens during the iteration, triggered by something that needs fixing right away rather than waiting for the scheduled checkpoint.