Scrum: Roles, Ceremonies, Artifacts

ScrumScrum is the most widely adopted concrete implementation of the values described in Agile: Origins and the Manifesto. It is a deliberately small framework — the official Scrum Guide is a short document, not a methodology textbook — built around a fixed rhythm of short iterations. What follows is the current terminology, verified against the guide's official site, plus the failure modes that show up when the rhythm is followed without the substance behind it.

The Three Accountabilities

TheThe 2020 revision of the Scrum Guide renamed the "Development Team" role to simply "Developers," folding it into a single Scrum Team with three accountabilities rather than a team-within-a-team¹:

Scrum.org's own account of the change is candid about the motive: the framework's authors said they had "always disliked" the old structure because it implied a subordinate team nested inside the Scrum Team, when accountability for the outcome is meant to be collective². If you're reading older material (or older job postings) that still says "Development Team," that's the pre-2020 term for the same role.

The Events

EveryEvery activity in Scrum happens inside a fixed-length container called the Sprint, and every other event is either inside it or bounds it:

The Artifacts and Their Commitments

EachEach Scrum artifact carries an associated commitment meant to keep it honest — a way of making the artifact's purpose measurable rather than aspirational:

The Definition of Done is the one most students underrate. It's a formal, shared checklist ("code reviewed, tests passing, deployed to staging," or whatever the team actually agrees) — without it, "done" quietly becomes whatever the loudest person in the room decides on any given day, which is exactly the ambiguity Scrum's cadence is supposed to remove.

Well-Documented Failure Modes

Scrum'sScrum's ceremonies are easy to copy and its substance is not, which is why most of its documented failures are ceremony-without-substance rather than the framework itself being wrong:

• "Zombie Scrum." Verwijs, Schartau and Overeem's Zombie Scrum Survival Guide names the pattern precisely: a team runs every event, produces every artifact, and yet the process is "slow, lifeless, and joyless" because the purpose behind each ceremony was never internalised³. The Daily Scrum becomes a status report to a manager rather than a re-planning conversation between developers; the Retrospective becomes a ritual with no resulting change.
• Scrum Master as project-manager-in-disguise. The role is defined as a servant-leader coaching the team and removing impediments, not as a task-assigner with a new title. In practice, organisations that haven't changed their underlying command structure often just rename the project manager "Scrum Master" and keep the old reporting relationship — which reintroduces the top-down control Scrum's accountability model is designed to avoid.
• Story-point gaming. Once velocity (points completed per Sprint) becomes a management metric rather than a team-internal planning aid, teams learn to inflate estimates to show a rising trend — Goodhart's Law applied to sprint planning. The number stops measuring throughput and starts measuring the team's understanding of what management wants to see.

None of these are flaws in the Scrum Guide itself, which is explicit about purpose throughout — they're what happens when an organisation adopts the form of Scrum to signal modernity without changing the incentives and trust structures the form depends on.

What Scrum Deliberately Doesn't Specify

ScrumScrum is a project-management and workflow framework — it says nothing about how code should actually be written. Teams commonly pair it with Extreme Programming for the engineering practices (pairing, TDD, continuous integration, refactoring) it leaves unaddressed, and with the testing discipline covered in TDD & BDD. A team that runs perfect Sprint ceremonies over undisciplined engineering will still ship unreliable software on schedule.

See Also

ForFor the philosophy Scrum implements, see Agile: Origins and the Manifesto. For the alternative flow-based framework with no fixed iteration or prescribed roles, see Kanban. For managing the risks a Sprint Retrospective is meant to surface, see Risk Management & Mitigation. For what the Sprint Retrospective should actually be doing with estimation specifically — comparing planned against actual, and feeding the difference back into the next Sprint Planning — see Estimating Effort and Time, and Why Retrospectives Make It Better.

References