What Is Scrum? Roles, Events & Artifacts [2026]
A. Togay Koralturk, Best-Selling PMP Author
Last updated on August 23, 2026
12 min read
Scrum is the most widely used agile framework in the world, and also one of the most widely misapplied — plenty of teams "do Scrum" without getting any of its benefits. The framework itself is deceptively simple: a handful of roles, events, and artifacts arranged around short, repeating cycles. What's hard is the mindset underneath, which asks teams to inspect reality and adapt rather than follow a fixed plan. This guide explains what Scrum is in full — where the name comes from, the theory behind it, its three roles, five events, and three artifacts, how it all works together, how it differs from agile, and how it appears on the PMP and CAPM exams.
What is Scrum?
Scrum is a lightweight agile framework that helps teams deliver complex products through short, iterative cycles, adapting as they learn rather than following a fixed long-term plan. It structures work into repeating sprints, each producing a usable increment of the product, and defines a small set of roles, events, and artifacts that make that possible.
The word "lightweight" is important — Scrum is deliberately minimal. It is a framework, not a full methodology: it tells you the essential roles and events to have and the artifacts to maintain, but it doesn't prescribe exactly how to do the work inside them. Teams add their own practices and techniques around the framework to fit their context. That intentional incompleteness is a feature, not a gap; Scrum provides just enough structure to enable inspection and adaptation, and leaves the rest to the team. It's used far beyond its software-development origins now, anywhere teams face complex work with changing requirements.
What does "Scrum" mean?
Despite how it's often written, Scrum is not an acronym — it doesn't stand for anything. The name comes from rugby, where a "scrum" is the tightly packed formation the team uses to restart play, moving down the field together as one unit. It was chosen as a metaphor for a cross-functional team working closely and self-organizing toward a shared goal.
The term entered product development through a 1986 Harvard Business Review article by Hirotaka Takeuchi and Ikujiro Nonaka, who used the rugby analogy to describe a faster, more collaborative approach to product development. In the 1990s, Ken Schwaber and Jeff Sutherland built on that idea to formalize the Scrum framework, later codifying it in the Scrum Guide, whose current version dates to 2020. So while the name sounds technical, its roots are athletic — a reminder that Scrum is fundamentally about a team moving together, not a rigid process or a piece of software.
Ready to take the next step in project management?
200,000+ Learners Trust Our Instructors
Scrum theory: empiricism and values
Scrum is founded on empiricism — the idea that knowledge comes from experience and that decisions should be based on what is actually observed, not on speculation or a detailed upfront plan. Because complex work is unpredictable, Scrum favors learning by doing in short cycles over trying to plan everything in advance. This empirical approach rests on three pillars:
- Transparency. The work and the process are visible to everyone involved, so decisions are made on a shared, accurate picture of reality.
- Inspection. The team frequently checks its progress and its product against the goal, catching problems early.
- Adaptation. When inspection reveals something is off, the team adjusts — the plan, the product, or the process — as soon as possible.
Underpinning the pillars are five Scrum values that make the framework actually work: commitment, courage, focus, openness, and respect. These aren't decorative — a team that inspects honestly needs openness and courage; one that adapts needs focus and commitment; and all of it depends on respect among team members. Scrum's mechanics only deliver value when a team genuinely lives these values; without them, the events and artifacts become empty ritual.
The Scrum team and roles
Scrum organizes people into a single Scrum team — one team, with no sub-teams or hierarchies, typically ten or fewer people, that is self-managing and cross-functional. Within it are three accountabilities, each with a distinct focus.
| Role | Accountable for |
|---|---|
| Product owner | Maximizing the product's value; owns and orders the product backlog. |
| Scrum master | The team's effectiveness and establishing Scrum; a servant leader who coaches and removes impediments. |
| Developers | Building a usable increment each sprint; they decide how the work gets done. |
The three roles cover the what, the how well, and the doing of the work: the product owner decides what to build and in what order, the scrum master ensures the team works effectively, and the developers build it. Crucially, the team is self-managing — no one outside the team tells it how to turn backlog items into an increment, and there's no "project manager" role directing the work inside Scrum. The three accountabilities together hold everything the team needs to deliver.
The 5 Scrum events
Scrum defines five events, all of which take place within the sprint. Each is a formal opportunity to inspect and adapt, and together they replace the endless, ad-hoc meetings that plague many teams with a predictable rhythm.
| Event | Purpose |
|---|---|
| The sprint | The container for all other events — a timebox of a month or less that produces a usable increment. |
| Sprint planning | Starts the sprint; the team sets a sprint goal and selects the work. |
| Daily scrum | A 15-minute daily sync for the developers to inspect progress and plan the day. |
| Sprint review | Near the sprint's end; the team and stakeholders inspect the increment and adapt the backlog. |
| Sprint retrospective | Closes the sprint; the team reflects on how to work better. |
The sprint is the heartbeat that contains the other four. A new sprint begins the moment the previous one ends, so the cycle of planning, daily coordination, review, and reflection repeats continuously — giving Scrum its steady, inspectable cadence.
The 3 Scrum artifacts
Scrum has three artifacts that represent work or value, each designed to maximize transparency. In the 2020 Scrum Guide, each artifact also carries a commitment — a target that gives it meaning and lets the team measure progress against it.
| Artifact | What it is | Its commitment |
|---|---|---|
| Product backlog | The ordered list of everything the product might need. | The product goal |
| Sprint backlog | The work selected for the current sprint, plus the plan to deliver it. | The sprint goal |
| Increment | A usable, "done" piece of the product delivered this sprint. | The definition of done |
The artifacts flow into one another: items from the product backlog are pulled into the sprint backlog at planning, and the developers turn them into an increment during the sprint. The commitments keep each artifact honest — the product goal gives the backlog direction, the sprint goal gives the sprint focus, and the definition of done sets the quality bar an increment must clear to count as finished. Without its commitment, each artifact would lose the transparency that makes it useful.
How Scrum works
Putting the pieces together, Scrum runs as a continuous loop. The product owner maintains an ordered product backlog aimed at the product goal. Each sprint begins with sprint planning, where the team selects the highest-priority work it can complete and shapes a sprint goal, forming the sprint backlog. During the sprint, the developers build the work, meeting each day at the daily scrum to coordinate and adapt their plan, guided along the way by the scrum master who clears impediments.
By the sprint's end, the team has produced a "done" increment. At the sprint review, the team shows that increment to stakeholders, gathers feedback, and adapts the product backlog in response. Then the sprint retrospective closes the sprint with a look at how the team can work better next time. And immediately, the next sprint begins — pulling the now-reprioritized top of the backlog into a fresh cycle. Each loop is a full turn of inspect-and-adapt: the team learns from a real, working increment and real feedback, then adjusts both the product and its process. That repeating empirical cycle, not any single event, is the essence of how Scrum works.
Scrum vs. agile
Scrum and agile are often used interchangeably, but they're not the same kind of thing. Agile is a philosophy — the mindset and values captured in the Agile Manifesto, describing what to value when developing products. Scrum is a specific framework — one concrete way to put that philosophy into practice, with defined roles, events, and artifacts.
The clean way to say it: all Scrum is agile, but not all agile is Scrum. Scrum is the most popular agile framework, but it's one of several — Kanban, Extreme Programming, and others are also agile without being Scrum. Choosing Scrum means adopting a particular structure for realizing agile values; a team could equally realize them through a different framework, or a blend like scrumban. So when someone says their team is "agile," that describes their mindset; when they say it's "doing Scrum," that describes the specific framework they've chosen to live that mindset out. Confusing the two leads teams to think adopting Scrum's mechanics automatically makes them agile — when the mindset is what actually matters.
Benefits and limitations
Scrum's structure delivers real advantages, but it isn't a fit for every situation:
- Benefit — fast feedback and adaptability: short sprints and frequent reviews surface problems and changes early, so the product stays aligned with real needs.
- Benefit — transparency and predictability: the events and artifacts make progress visible and give the team a dependable rhythm.
- Benefit — frequent value and ownership: a usable increment every sprint delivers value sooner, and self-management builds a committed, accountable team.
- Limitation — it demands culture change: Scrum needs empowered roles, self-organization, and genuine buy-in; imposed on a command-and-control culture, it stalls.
- Limitation — it suits complex, changing work: for simple, highly predictable work with fixed requirements, Scrum's overhead may add little over a straightforward plan.
The most common failure isn't Scrum itself but "Scrum in name only" — adopting the meetings and labels while ignoring the empiricism and values beneath them. A team that runs the events but never truly inspects and adapts gets the cost of Scrum without the benefit. Used with its mindset intact, though, Scrum is a proven way to deliver complex work.
Scrum on the PMP® and CAPM® Exams
Because the current PMP exam devotes a large share of its content to agile and hybrid delivery, Scrum is among the most heavily represented frameworks on it. You're expected to know its roles, events, and artifacts, and — more importantly — the empirical, self-managing mindset behind them: transparency, inspection, and adaptation over detailed upfront planning and control.
Situational questions tend to test that mindset rather than definitions. Watch for scenarios where a team runs Scrum mechanically but skips its substance, where someone tries to impose command-and-control on a self-managing team, or where fixed, change-resistant planning collides with Scrum's adaptive cycle — the right answers protect empiricism, the team's self-management, and the delivery of a working increment each sprint. The exam also tests role boundaries and the purpose of each event and artifact. Our PMP Complete Study Guide, the most complete on the market, covers Scrum and the wider agile landscape as the exam frames them.
PMP Practice Question: Scrum
A Scrum team ships a "done" increment every two weeks, holds every Scrum event on schedule, and has kept a stable velocity for a year. Yet the product is steadily losing users. Looking closer, the project manager finds that sprint reviews are attended only by internal managers, who approve each demo; product usage data is not shared with the team, "to keep developers focused"; and the product backlog's ordering has not changed in six months.
What is the most likely reason Scrum is not delivering value here?
a) The events have drifted from the Scrum Guide's formats, and the team should be re-trained to run them to their defined timeboxes and structures.
b) The empirical loop has no real input: with only internal approvers at the review and usage data withheld, inspection examines nothing true about the product, so nothing adapts.
c) Scrum is operating as intended, and the product's decline is a market and product-strategy problem that sits outside the delivery framework.
d) The team lacks a discovery mechanism, and a dedicated discovery sprint each quarter would reconnect the roadmap with users.
Correct answer: B.
Rationale: Scrum's engine is empiricism — transparency feeding inspection feeding adaptation — and this organization has quietly cut the loop's inputs while preserving its ceremonies. A review attended only by managers who approve the demo inspects the team's obedience, not the product's value; withholding usage data removes the other honest signal; and the frozen backlog is the visible proof that no adaptation is occurring, since a backlog that never reorders is a plan, not a living artifact. Choice a) is the mechanical misdiagnosis, because the events are running fine as theater and better-formatted theater is still theater. Choice c) is the tempting separation argument, but deciding what is valuable is inside Scrum: it is the product owner's accountability, exercised through exactly the feedback channels that have been severed. Choice d) treats continuous feedback as a quarterly appointment, parking the problem in a new ritual instead of restoring real users and real data to the events that already exist. To sharpen this kind of diagnosis skill, work through our PMP practice exams or, at the entry level, our CAPM practice exams.
Ready to take the next step in project management?
200,000+ Learners Trust Our Instructors
Frequently asked questions
What is Scrum?
Scrum is a lightweight agile framework that helps teams deliver complex products through short, iterative cycles called sprints, adapting as they learn rather than following a fixed long-term plan. It defines three roles, five events, and three artifacts arranged around sprints, each of which produces a usable increment of the product. It is a framework rather than a full methodology, providing just enough structure to enable inspection and adaptation.
What does Scrum stand for?
Scrum is not an acronym and doesn't stand for anything. The name comes from rugby, where a scrum is the formation a team packs into to restart play and move down the field together. It was adopted as a metaphor for a cross-functional team working closely and self-organizing toward a shared goal, first in a 1986 Harvard Business Review article and later in the Scrum framework formalized by Ken Schwaber and Jeff Sutherland.
What is the difference between Scrum and agile?
Agile is a philosophy — the mindset and values described in the Agile Manifesto — while Scrum is a specific framework that puts that philosophy into practice with defined roles, events, and artifacts. All Scrum is agile, but not all agile is Scrum: other frameworks such as Kanban and Extreme Programming are also agile. Adopting Scrum is one way to realize agile values, not the only way.
What are the Scrum roles?
Scrum has three roles, or accountabilities, within a single Scrum team: the product owner, who maximizes the product's value and owns the product backlog; the scrum master, who is accountable for the team's effectiveness and establishing Scrum as a servant leader; and the developers, who build a usable increment each sprint and decide how the work gets done. The team is self-managing, with no separate project manager directing the work.
What are the Scrum events?
Scrum has five events, all held within the sprint: the sprint itself, which is a timebox of a month or less containing the others; sprint planning, which starts the sprint and sets a sprint goal; the daily scrum, a 15-minute daily sync for the developers; the sprint review, where the team and stakeholders inspect the increment and adapt the backlog; and the sprint retrospective, which closes the sprint by reflecting on how to improve.
What are the Scrum artifacts?
Scrum has three artifacts: the product backlog, the ordered list of everything the product might need; the sprint backlog, the work selected for the current sprint plus the plan to deliver it; and the increment, a usable "done" piece of the product delivered each sprint. Each has a commitment — the product goal, the sprint goal, and the definition of done, respectively — that gives it direction and transparency.
Is Scrum on the PMP exam?
Yes. The current PMP exam covers agile and hybrid delivery heavily, and Scrum is one of the most represented frameworks. You are expected to know its roles, events, and artifacts, and to apply the empirical, self-managing mindset behind it — favoring transparency, inspection, and adaptation over rigid upfront planning — in situational questions.
Is Scrum on the CAPM exam?
Yes. The CAPM covers Scrum as a core part of its agile content, usually a little more directly than the PMP — often testing the roles, events, artifacts, or the meaning of empiricism. Because the CAPM is scenario-based, you should also be ready to recognize when Scrum is being applied in name only, without its underlying values and empirical cycle.
Scrum Master: Role, Responsibilities & Skills [2026]
A scrum master is a servant leader who helps a team work effectively. Responsibilities, scrum master vs. project manager, skills, becoming one, and exam tips.
Product Owner: Role, Responsibilities & Skills [2026]
The product owner maximizes a product's value and owns the backlog. Responsibilities, product owner vs. scrum master, skills, how to become one, and exam tips.
What Is a Sprint in Agile? Length & Cycle [2026]
A sprint is a short, fixed-length iteration that delivers a done increment. Sprint length, the sprint cycle and events, sprint vs. scrum, and PMP exam tips.
