Scrum Framework: Accountabilities, Artifacts, Events, and What Changed
Scrum is a framework for delivering work in sprints of a month or less, defining three accountabilities, three artifacts and five events, and leaving everything else to the team.
Before you start
Is this your framework?
Scrum answers one question: how does a team organize itself to deliver something every few weeks and adjust as it learns. It specifies who is accountable for what, what gets written down, and when the team stops to inspect.
It is deliberately incomplete. Scrum has nothing to say about estimation, engineering practice, scaling or how to run a backlog well, and treating it as a complete method is the usual reason it disappoints.
| If your real problem is… | You probably want |
|---|---|
| We want the detail of what happens across a sprint, day by day | The Agile Sprint Cycle — the events in sequence, their timeboxes and what each produces Compare Scrum and the Sprint Cycle |
| Work arrives continuously and fixed-length sprints fight against it | Kanban — flow and work-in-progress limits, with no iteration boundary Compare Scrum and Kanban |
| We need to decide what to build, not how to organize building it | RICE — Scrum assumes a prioritized backlog and never says how to make one |
| The backlog is a flat list nobody can see the product in | User Story Mapping — structure for the backlog Scrum takes as given |
| Adopting this will fail on resistance, not on mechanics | Kotter's 8-Step Process — organizational change, which no framework supplies |
| We need to improve a process rather than deliver a product | Kaizen — continuous improvement of how work is done |
| A team needs a delivery rhythm, clear accountability, and regular points to correct course | Scrum — you are in the right place |
What Is It?
Scrum fits in about thirteen pages. It names three accountabilities, three artifacts and five events, says a sprint lasts a month or less, and stops. That brevity is the design: the framework is meant to be minimal, and to make problems visible rather than to solve them.
The mechanism is a short loop with fixed inspection points. Work is pulled from a backlog into a sprint, the team meets daily to replan, and at the end there are two separate reviews — one of the product, one of how the team worked. Nothing in that is clever. What it does is make it impossible to go more than a few weeks without finding out where you are.
What Scrum does not contain is the part that surprises people. There is no guidance on estimation, story points, velocity, engineering practice, backlog refinement technique, or how to scale beyond one team. All of those are common, useful and added from outside. When someone says Scrum did not work, the thing that failed is usually one of these additions.
The framework also changed substantially in November 2020, and much of what is published about it did not. There is no longer a Development Team, there are no roles, and the three daily questions are gone. Those are not cosmetic edits; each removed something that was actively causing a common failure.
The honest summary: Scrum is a rhythm and a set of accountabilities, not a method. It works when an organization is willing to act on what the rhythm reveals, and becomes an expensive meeting schedule when it is not.
Quick Reference
Structure
Accountabilities, artifacts and events
Three groups, and since 2020 each artifact is paired with a commitment — something it is measured against. That pairing is the part most descriptions still omit.
| Accountability | Answerable for | Where it goes wrong |
|---|---|---|
| Product Owner | The value of the product and the ordering of the Product Backlog. One person, not a committee. | Held by someone without authority to decide, so every ordering decision escalates and the sprint waits. |
| Scrum Master | The team's effectiveness, and removing what impedes it. A leader who serves, in the current wording. | Reduced to running meetings and updating a board. The accountability is for effectiveness, which usually means changing things outside the team. |
| Developers | Creating a usable Increment each sprint, and how the work gets done. Everyone doing the work, not only programmers. | Read as software engineers only, which excludes designers, testers and writers who are part of the same accountability. |
| Artifact | Its commitment | What the pairing is for |
|---|---|---|
| Product Backlog | Product Goal | A single longer-term objective the backlog is ordered against, so sprints add up to something rather than accumulating. |
| Sprint Backlog | Sprint Goal | One reason this sprint is worth running. If the goal cannot be stated in a sentence, the sprint is a list of tasks. |
| Increment | Definition of Done | A shared standard for what finished means. Without it, done drifts per person and the increment is not usable, which is the failure this pairing exists to prevent. |
| Event | Timebox | What it is for, and how it fails |
|---|---|---|
| The Sprint | A month or less | The container for everything else. A new one starts the moment the last ends. Extending it to finish work removes the fixed cadence that makes overcommitment visible. |
| Sprint Planning | Up to 8 hours | Answers why this sprint is valuable, what can be done, and how. The first question was added in 2020 and is the one teams skip. |
| Daily Scrum | 15 minutes | The Developers replan the day against the Sprint Goal. Fifteen minutes whatever the sprint length. Fails as a status report to a manager. |
| Sprint Review | Up to 4 hours | Stakeholders inspect the actual Increment and the backlog is adjusted. Fails as a slide presentation with nothing running. |
| Sprint Retrospective | Up to 3 hours | The team inspects how it worked, not what it built. Merging it into the Review reliably means this is the one that gets dropped, because product feedback is louder. |
Why the Sprint is itself listed as an event
Counting the Sprint itself as an event reads oddly until you notice what it is doing: it is the container the other four sit inside, and it has its own rule, that a new one begins the moment the last ends. There is no gap between sprints in which work is planned or tidied up. That immediacy is the constraint doing the work, and it is the first thing organizations quietly drop.
Sprint Planning covers three topics in the current Guide: why this sprint is valuable, what can be done, and how the work will get done. The first was added in 2020 and is the one teams skip. A sprint that answers only what and how produces a batch of tickets with no stated reason for existing.
Current version
What the 2020 revision removed
The Scrum Guide was revised in November 2020 and the changes were substantial. Much of what is published about Scrum, including training material and diagrams, still describes the earlier version.
| Before | Now | Why |
|---|---|---|
| Development Team, inside the Scrum Team | Developers. One team, no sub-teams. | A team within a team produced us-and-them behavior between the Product Owner and everyone else. Removing the inner team removes the boundary it created. |
| Roles | Accountabilities | To stop them being read as job titles. They are sets of responsibilities, and one person can hold more than one. |
| The three daily questions | Nothing prescribed | The script turned the Daily Scrum into a status report to the Scrum Master. Made optional in 2017, removed in 2020. Any structure is fine if it replans the day against the Sprint Goal. |
| Servant-leader | A leader who serves | Word order, deliberately. Servant-leader was being read as scribe and meeting organizer rather than as someone accountable for changing what blocks the team. |
| Self-organizing | Self-managing | Self-organizing described who does the work. Self-managing adds choosing what to work on and how, which is a larger claim. |
| Artifacts standing alone | Each paired with a commitment | Product Goal was new. It gave the Product Backlog something to be ordered against, which it previously lacked. |
Why the vocabulary matters more than it sounds
These read as terminology changes and are mostly not. Each one was aimed at a specific behavior the earlier wording produced: a status meeting, a Scrum Master who books rooms, a Product Owner treated as an external customer. The Guide got shorter because being more prescriptive had made it worse, and the removals are the substance of the revision.
The practical consequence for anyone learning Scrum now is that the year of your source matters. Material describing a Development Team, three roles, or a daily stand-up script is at least five years out of date, and it is describing the version whose specific failures the current Guide was written to correct.
Core Features
- Sprints of a month or less: a new one starts as the last ends
- Three accountabilities: Product Owner, Scrum Master, Developers
- Three artifacts, each with a commitment: Product Goal, Sprint Goal, Definition of Done
- Five events: the Sprint containing Planning, Daily Scrum, Review, Retrospective
- One team, no sub-teams: and no hierarchy within it
- Deliberately incomplete: silent on estimation, practice and scaling
Worked example
Three years of Scrum, and a script withdrawn in 2020
An illustrative composite. A 40-person insurance software company in Wellington, New Zealand, running four teams that had used Scrum for three years. Delivery was slow, morale was poor, and a consultant had been asked to fix the ceremonies.
| What was examined | What it showed |
|---|---|
| The Daily Scrum | Fifteen minutes had become forty. Each person answered the three questions to the Scrum Master, who wrote them down. The team was following a script removed from the Guide five years earlier, from training material bought in 2018. |
| The Product Owner | Held by a business analyst who could not change the order of the backlog without sign-off from two directors. Median time to get an ordering decision: eleven days, against a two-week sprint. |
| Sprint Goals | Of the last 26 sprints across four teams, 3 had a stated goal. The rest had a list of tickets. Nobody could say why any particular sprint had been worth running. |
| Definition of Done | Written once in 2022, never revised, and interpreted three different ways across the teams. Work counted as done at each team's own boundary, so integration failures surfaced two sprints later. |
| What changed | Ordering authority moved to the Product Owner outright. A one-sentence Sprint Goal became a condition of starting a sprint. The Definition of Done was rewritten by all four teams together. The daily script was dropped. |
The ceremonies were the symptom
The request was to fix the meetings. The meetings were fine in structure and pointless in substance, because a Product Owner who cannot reorder a backlog is not a Product Owner, and a sprint without a goal is a batch of tickets with a deadline. Neither is fixable by running a better stand-up.
Note where the daily script came from. Not carelessness — 2018 training material, accurately reflecting the Guide as it stood. The team was doing correctly what it had been taught, and what it had been taught had been withdrawn. That is worth checking in any long-running Scrum adoption, because nothing in the framework prompts a team to re-read its own definition.
When to Use
- Work is complex enough that the plan will need revising as you learn
- A team of ten or fewer can be dedicated to one product
- Something usable can plausibly be produced within a month
- A single person can be given real authority over what gets built next
- The organization will act on what the reviews and retrospectives surface
- Stakeholders will turn up to look at working software regularly
When NOT to Use
- Work arrives continuously and unpredictably, where a fixed sprint fights the flow
- The requirements are genuinely stable and well understood
- No one person can be given authority over the backlog
- Nothing usable can be produced in under a month, however thin
- Retrospective findings will not be acted on, which makes the event theatre
- The team is fragmented across several products or many part-time members
Current version
How Scrum goes wrong
Most Scrum failures are not failures of Scrum. They are the organization declining to change something the framework made visible.
| Failure mode | What it looks like | What to do instead |
|---|---|---|
| A Product Owner without authority | Every ordering decision escalates, and sprints wait on sign-off | Give the accountability to someone who can decide, or accept that you are not running Scrum. |
| Sprints with no goal | A list of tickets and a deadline. Nobody can say why the sprint was worth running. | Require one sentence before the sprint starts. If it cannot be written, the sprint is not ready. |
| The Daily Scrum as status report | Everyone reports to the Scrum Master in turn, and it overruns | Drop the script, which the Guide removed in 2020. Replan the day against the Sprint Goal instead. |
| Retrospective findings ignored | The same items surface every sprint, and attendance quietly declines | Carry one improvement into the next Sprint Backlog. If nothing is ever actioned, stop holding it. |
| Velocity as a target | Points inflate, delivery does not change, and estimates stop being useful | Velocity is a capacity input, not a performance measure. Never report it upward as one. |
| An unshared Definition of Done | Done means different things per team, so integration problems surface sprints later | Write it together across teams and revise it. It is a commitment, not documentation. |
| Out-of-date practice | Development Team, three roles, a daily script — all withdrawn in 2020 | Re-read the current Guide. It is thirteen pages and takes half an hour. |
Sourced
Evidence, and how to cite it
The 2020 revision removed vocabulary most descriptions still use.
The Scrum Guide published on 18 November 2020 eliminated the Development Team in favor of one Scrum Team with three accountabilities, replaced roles with accountabilities, removed the three Daily Scrum questions, changed servant-leader to a leader who serves, changed self-organizing to self-managing, and introduced the Product Goal alongside commitments for each artifact. Schwaber has said the aim was to remove a separate team that produced us-and-them behavior; Sutherland described the intent as addressing servant leaders who do not lead and self-organizing developers who do not meet commitments. The Guide was made shorter and less prescriptive because prescriptiveness had made it worse.
Schwaber, K. and Sutherland, J. (2020) The Scrum Guide; revision notes published at scrumguides.org.
The name comes from a 1986 paper about hardware, not software.
Hirotaka Takeuchi and Ikujiro Nonaka used the rugby scrum as a metaphor in "The New New Product Development Game" in the Harvard Business Review in 1986, describing how companies including Honda, Canon and Fuji-Xerox developed products with overlapping phases and self-organizing teams rather than a relay handoff. It was about physical product development. Sutherland has credited Nonaka's use of the word directly. Scrum as a software process came later: Sutherland and Schwaber ran the first one in 1993 and presented it at OOPSLA in 1995.
Takeuchi, H. and Nonaka, I. (1986) ‘The New New Product Development Game’, Harvard Business Review, January-February; Sutherland, J. and Schwaber, K. (1995) ‘SCRUM Development Process’, OOPSLA.
Most of what teams call Scrum is not in Scrum.
Story points, velocity, planning poker, burndown charts, backlog refinement technique, three-amigos sessions and every scaling framework are additions. None appears in the Guide. This matters because when a Scrum adoption fails, the thing that failed is usually one of these, and the framework takes the blame for a practice it never specified. It also means two organizations can both be doing Scrum correctly and look almost nothing alike.
Comparison of common practice against the text of the 2020 Scrum Guide, which runs to roughly thirteen pages.
There is no reliable evidence that Scrum outperforms alternatives.
Surveys of agile adoption are numerous, mostly run by organizations selling training or tooling, and rely on self-reported success. Controlled comparison against other ways of organizing the same work barely exists, and the teams that adopt Scrum differ systematically from those that do not. The defensible claim is narrower and still useful: a short fixed cycle with mandatory inspection points shortens the time between doing something and finding out whether it worked. That is a mechanism, not a measured advantage.
Assessment of the software engineering and management literature as of 2026; industry agile surveys are vendor-published and self-reported.
How to cite it.
Harvard: Schwaber, K. and Sutherland, J. (2020) The Scrum Guide. Available at scrumguides.org.
APA: Schwaber, K., & Sutherland, J. (2020). The Scrum Guide.
Always give the year, because the Guide is revised and the 2020 vocabulary differs materially from earlier versions. For the origin of the name, cite Takeuchi and Nonaka (1986).
Key Strengths
- Short feedback loop: you cannot go a month without finding out where you are
- Clear accountability: one person answerable for order, one for effectiveness
- Makes problems visible: the events surface what a longer cycle would hide
- Minimal: thirteen pages, learnable in an afternoon
- Widely understood: new team members usually arrive knowing the vocabulary
Key Weaknesses
- Silent on most of the job: estimation, engineering practice and scaling are yours
- Only works if the organization acts: it reveals problems it cannot fix
- Fixed cycles fight continuous work: a poor fit for support and operations
- Meeting-heavy if the events are hollow: the same schedule with none of the value
- Widely taught out of date: a lot of material still describes the pre-2020 version
Sequencing
What to run before and after
Scrum organizes delivery. It assumes somebody has already decided what is worth delivering.
Before
Get a backlog worth ordering, and someone who can order it
Scrum assumes a prioritized Product Backlog and never says how to produce one. Without structure and a real decision-maker, the sprint mechanics run over nothing.
During
Run the cycle, and watch what the events surface
The detail of what happens across a sprint, and the timeboxes for each event, sit on the sprint cycle page. The value is in acting on what the reviews reveal.
After
Act on the retrospectives, or stop holding them
A retrospective whose findings are never actioned trains a team that inspection is decorative. Improvement has to leave the room and land somewhere with an owner.
Common questions
Scrum: quick answers
What is the Scrum framework?
A lightweight framework for delivering work in short cycles called sprints. It defines three accountabilities, three artifacts and five events, and very little else. Most of what teams call Scrum is added around it rather than specified by it, which is deliberate: the framework is meant to be minimal and to expose problems rather than solve them.
What are the three accountabilities in Scrum?
Product Owner, Scrum Master and Developers. They were called roles until 2020, when the wording changed to accountabilities to make the point that they are sets of responsibilities rather than job titles. One person can hold more than one, and Developers means everyone doing the work, not only programmers.
Is there still a Development Team in Scrum?
No. The 2020 Scrum Guide removed it. There is one Scrum Team containing all three accountabilities, with no sub-teams and no hierarchy inside it. The change was made because a separate Development Team encouraged an us-and-them relationship with the Product Owner. Descriptions still using the term are describing Scrum as it was before November 2020.
What are the three artifacts and their commitments?
Product Backlog, committed to the Product Goal. Sprint Backlog, committed to the Sprint Goal. Increment, committed to the Definition of Done. The pairing was introduced in 2020: each artifact now has a commitment that gives it something to be measured against, and the Product Goal was a new concept at that point.
What are the five Scrum events?
The Sprint, which contains the others, plus Sprint Planning, the Daily Scrum, the Sprint Review and the Sprint Retrospective. A sprint is a month or less and a new one starts immediately after the last ends. The events exist to create regular points at which to inspect and adapt, which is why skipping one tends to be felt later rather than immediately.
Are the three daily questions still part of Scrum?
No. What did I do yesterday, what will I do today, what is in my way were made optional in 2017 and removed entirely in 2020. Developers choose any structure they like for the Daily Scrum, as long as it focuses on progress toward the Sprint Goal and produces a plan for the day. The questions turned the event into a status report, which was never its purpose.
Who created Scrum?
Ken Schwaber and Jeff Sutherland, who ran the first Scrum in 1993 and presented the process at the OOPSLA conference in 1995. The name came from earlier work: Hirotaka Takeuchi and Ikujiro Nonaka used the rugby scrum as a metaphor in a 1986 Harvard Business Review article about product development at companies such as Honda and Canon, which was about hardware rather than software.
How do you cite Scrum?
Cite the Scrum Guide itself, which is the definitive source and is revised: Schwaber, K. and Sutherland, J. (2020) The Scrum Guide. Give the year, because the 2020 revision changed the vocabulary substantially. For the origin of the name, cite Takeuchi, H. and Nonaka, I. (1986) in Harvard Business Review.
Deep Resources
Frameworks related to Scrum
- The Agile Sprint CycleWhat happens across a sprint day by day, and what each event produces…
- KanbanContinuous flow with no iteration boundary, for work that arrives unpredictably…
- User Story MappingStructure for the backlog Scrum assumes you already have…