Loading content
Retrospectives are facilitated team meetings for continuous improvement of practices, processes, and collaboration. They surface actionable improvements, reflect on past iterations, and foster a learning culture. With structured facilitation, prioritization and action tracking, improvements become tangible and can be shared across teams at the domain level.
Use this profile to understand the building block briefly, place it in the model, and switch to the 360° assessment when needed.
Executable approach: can be applied and produces an outcome.
What organizes, connects, or makes decisions possible.
Retrospectives are facilitated team meetings for continuous improvement: they surface what happened, derive concrete improvements, and re-check them in the next work cycle.
In agile teams, the (sprint) retrospective gained a particularly explicit, named formalization through Scrum: the Scrum Guide defines an event at the end of every Sprint called “Sprint Retrospective”, where the team identifies “lessons and improvements” for upcoming Sprints. The event is tied to Scrum’s empirical mechanism—transparency, inspection, and adaptation. The Scrum Guide was first written in 2010 and has been evolved through later revisions/updates; the current published version is dated November 2020. This revision history is provenance for the Scrum event guidance, not evidence that the broader general practice of retrospectives originated there.
Run retrospectives as an insight → decision → change loop: the team reviews the last cycle with a clear facilitation frame, compresses observations into the most actionable learning points, chooses a small set of improvement experiments, and defines how the team will later recognize whether the change is working—then feeds the results into the next cycle.
The group works with guidance so discussions turn into decisions the team can reuse, rather than staying at opinion or blame.
Retrospective timing is anchored to a repeatable work frame (e.g., sprint end), making learning regular and manageable.
Reflection is meant to produce targeted improvements that can be tried out concretely in the next work phase.
Within Scrum, retrospectives align with the idea that what becomes visible should be inspected and then adapted (transparency → inspection → adaptation).
Whether an action works is verified later via an observable outcome; without that revisit, learning stays abstract.
Retrospectives help most when teams work in recurring cycles (for example after sprints or other iterations) and want to systematically refine how they deliver. The biggest payoff comes from converting reflection into changes that can be re-checked in the next cycle. Limits/trade-offs: too wide a topic range overwhelms prioritization; overly vague improvements can’t translate into a perceivable process change. Without ownership and follow-up, retrospectives commonly degrade into a retrospective conversation without durable learning.
Where this building block is located in the topic model.
Explore how this building block connects to concepts, methods, technologies, and tools.
These sources establish the term and its professional meaning.
All direct connections of the current building block in a compact text view.
This classification shows where the building block typically matters, how demanding it is, and what kind of impact it has in the model.
The level within the organization (enterprise, domain, team) at which the AssetBlock is applied.