Ceremony

Origin & evolution

The events come from Scrum, which Ken Schwaber and Jeff Sutherland first co-presented at the OOPSLA conference in 1995 and have maintained ever since through the Scrum Guide (Wikipedia)). Scrum defines events inside each sprint: sprint planning, the daily scrum, the sprint review, and the sprint retrospective, with the sprint itself acting as the container. The daily scrum is held to fifteen minutes; each event exists to make a particular kind of inspection and adaptation happen on a cadence (Scrum Guide).

"Ceremony" is the popular name, not the official one. The Scrum Guide calls them events, and the community adopted "ceremony" and "agile ceremony" as the everyday term (Atlassian). The label has drawn criticism for implying performance over purpose, which is the exact failure mode practitioners warn against, and recent Scrum framing has leaned harder on "event" for that reason. The graph keeps "ceremony" as the entity because it is the word teams actually search and speak.

The live debate is whether ceremonies earn their cost. A team running four event types across a two-week sprint can spend a meaningful share of its capacity in scheduled meetings, and the retrospective is the one event whose job🔨JobUserJob To Be Done: what the user is trying to accomplishView reference → is to question the others. Healthy practice treats every ceremony as cuttable: if a standup has become a status read-out to a manager rather than coordination among the people doing the work, it has slipped from working event to theatre.

How it works in practice

A seven-person product team runs a two-week sprint. Planning opens it: the team pulls a sprint goal and the items it believes it can finish. The daily scrum, fifteen minutes each morning, surfaces blockers rather than reporting progress to a lead. The review closes the sprint with working software shown to stakeholders🧑‍💼StakeholderTeam & OrganisationA person with influence over the productView reference →, who give feedback that reshapes the next backlog. The retrospective, held last, inspects how the team worked and commits to one change.

Three sprints in, the retrospective flags that the daily scrum has become a round-robin status update nobody acts on. The team makes one change: the standup now starts from the board's right-most column and only discusses items that are stuck. Within two sprints the meeting runs to eight minutes and actually unblocks work. The ceremony stayed; its ritual content got cut. That self-correction is the mechanism working as designed.

Ceremony vs. its neighbours

• Meeting is any gathering called for a purpose, once or recurring, with whatever shape it needs🫀NeedUserA user need, pain, desire, or constraintView reference →. A ceremony is a specific, named, recurring event with a fixed cadence and a defined output. Every ceremony is a meeting; most meetings are not ceremonies.
• Retrospective is one ceremony, the one whose subject is the team's own process. It sits beneath the general concept as a particular instance, and it is the event that polices whether the other ceremonies still earn their place.
• Sprint is the time-box the ceremonies punctuate, the container event that holds planning at its start and review and retrospective at its end. The sprint is the interval; the ceremonies are the fixed points within it.

In the graph

In the Unified Product Graph, a ceremony is a leaf in the Operations & Quality region, within the team and organisation domain. It connects through team_practices_ceremonyTeampracticesCeremonyhierarchy and the reciprocal ceremony_involves_teamCeremonyinvolvesTeamcross-domain, binding the event to the people who run it, and through user_advisory_board_convenes_as_ceremonyUser Advisory Boardconvenes asCeremonyhierarchy, which lets a recurring user-facing forum be modelled as a ceremony in its own right. Tying every ceremony to a team is what keeps it honest in the graph: a ceremony with no practising team is a calendar entry without owners, and that orphan state is exactly the ritual-without-purpose risk🎲RiskComplianceA risk to the product or businessView reference → made visible.