What Is Scrum? Roles, Events and Artifacts in Plain English

Scrum is a lightweight framework for doing complex work in short, fixed cycles called Sprints, each one month or less. A small team, one Product Owner, one Scrum Master and the Developers, typically ten people or fewer, agrees on a goal for the Sprint, builds a usable piece of the product, shows it to the people it is for, and adjusts both the product and its own way of working before the next Sprint starts. The whole framework is defined in one short document, the Scrum Guide, and it fits on a page: three accountabilities, five events, three artifacts with a commitment each, and five values.

Scrum meaning: where the word comes from

The word is borrowed from rugby, where a scrum is the tight formation in which the two packs push against each other to restart play. The Agile Alliance glossary↗ (opens in a new tab) traces the software use to a 1986 Harvard Business Review article by Hirotaka Takeuchi and Ikujiro Nonaka, “The New New Product Development Game,” which described a “rugby approach” where a hand-picked, multidisciplinary team works together from start to finish instead of handing work down a line.

In project work, Scrum with a capital S means one specific thing: the framework Ken Schwaber and Jeff Sutherland developed in the early 1990s and first presented together in 1995. The 2020 Scrum Guide↗ (opens in a new tab) defines it as “a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.” As of September 30, 2026, the November 2020 edition is still the current one.

The idea underneath: inspect and adapt

Scrum rests on empiricism, the idea that knowledge comes from experience and decisions should be based on what is observed, and on lean thinking, which cuts waste. It turns that into three pillars. Transparency: the work and the process are visible to the people doing it and the people receiving it. Inspection: the artifacts and the progress toward goals are checked often. Adaptation: when something drifts outside acceptable limits, the process or the product is adjusted as soon as possible.

Every event is a scheduled chance to inspect and adapt. Beyond that, the guide calls Scrum “purposefully incomplete”: it sets the rhythm and the accountabilities, and leaves the techniques, such as user stories, estimation methods and boards, to the team.

The three accountabilities

The 2020 guide talks about accountabilities rather than roles. The Scrum Guide revision notes↗ (opens in a new tab) explain the change: the separate Development Team is gone, and there is now one Scrum Team focused on one objective, with three sets of accountabilities.

• Product Owner: accountable for maximizing the value of the product. They develop and communicate the Product Goal, create and order the Product Backlog items, and keep the backlog visible and understood. The Product Owner is one person, not a committee.
• Scrum Master: accountable for Scrum being practiced as the guide defines it and for the team’s effectiveness. They coach the team, cause impediments to be removed, and make sure the events happen and stay within their timeboxes. What does a Scrum Master do? covers the role in full.
• Developers: everyone who creates the Increment, whatever their skill. They are accountable for the Sprint plan, for quality through the Definition of Done, for adapting the plan each day toward the Sprint Goal, and for holding each other accountable as professionals.

The team is cross-functional, with every skill needed to deliver, and self-managing: it decides internally who does what, when and how, with no sub-teams or hierarchy.

The five events

The Sprint contains the other four. The timeboxes below are maximums for a one-month Sprint; the guide says shorter Sprints usually have shorter events.

• The Sprint: a fixed length of one month or less, with the next starting as soon as the last ends. During it, no change is made that would endanger the Sprint Goal, quality does not drop, and scope can be clarified and renegotiated with the Product Owner. Only the Product Owner can cancel a Sprint.
• Sprint Planning, up to eight hours: the team answers why this Sprint is valuable, what can be Done, and how. The sprint planning meeting post has an agenda and a template.
• Daily Scrum, 15 minutes: the Developers inspect progress toward the Sprint Goal and adjust the plan for the next day, at the same time and place every working day. Daily standup covers formats that work.
• Sprint Review, up to four hours: the team shows the results to key stakeholders and they decide together what to do next. The guide calls it a working session, not a presentation.
• Sprint Retrospective, up to three hours: it closes the Sprint. The team looks at how it worked and picks the most helpful changes. Sprint review vs retrospective sets the last two apart, and sprint retrospective questions has formats.

The three artifacts and their commitments

Each artifact carries a commitment, a fixed point that progress is measured against. The pairing arrived with the 2020 edition, which added the Product Goal and gave the Sprint Goal and the Definition of Done a formal home.

• Product Backlog, committed to the Product Goal. The backlog is an ordered, always-changing list of what the product needs, and the single source of work for the team. The Product Goal is the long-term objective; the team fulfills or abandons one before taking on the next.
• Sprint Backlog, committed to the Sprint Goal. It holds the Sprint Goal (why), the items selected for the Sprint (what) and the Developers’ plan for delivering them (how). It belongs to the Developers and changes throughout the Sprint as they learn.
• Increment, committed to the Definition of Done. An Increment is a usable step toward the Product Goal. Work that does not meet the Definition of Done is not part of it: it cannot be released or even shown at the Sprint Review, and it goes back to the Product Backlog.

The two backlogs are compared side by side in product backlog vs sprint backlog, and there are four working examples in definition of done examples.

The five Scrum values

• Commitment: the team commits to its goals and to supporting each other.
• Focus: attention stays on the work of the Sprint.
• Openness: the team and its stakeholders are open about the work and its problems.
• Respect: members treat each other as capable, independent people.
• Courage: people do the right thing and take on tough problems.

A one-page Scrum cheat sheet

TEAM      1 Product Owner + 1 Scrum Master + Developers (typically 10 or fewer)
PILLARS   transparency · inspection · adaptation
VALUES    commitment · focus · openness · respect · courage

EVENTS (maximum for a one-month Sprint; shorter Sprints, shorter events)
Sprint ............... 1 month or less, back to back, holds all the others
Sprint Planning ...... up to 8 h  -> Sprint Goal + selected items + plan
Daily Scrum .......... 15 min     -> progress toward the Sprint Goal, next day's plan
Sprint Review ........ up to 4 h  -> what was done, what to do next, with stakeholders
Sprint Retrospective . up to 3 h  -> how to work better next Sprint

ARTIFACT           COMMITMENT            WHO
Product Backlog -> Product Goal          Product Owner orders it
Sprint Backlog  -> Sprint Goal           Developers plan it
Increment       -> Definition of Done    Developers meet it

WHO DECIDES
What to build, in what order .... Product Owner
How much fits, and how .......... Developers
Cancel a Sprint ................. Product Owner only
Scrum practiced as defined ...... Scrum Master (accountable)

NOT IN THE GUIDE: story points, velocity, user stories, boards, burndown charts

The last line matters most: if a practice your team follows is not on this page, it is a technique you added, not part of Scrum. The guide mentions burn-downs, burn-ups and cumulative flow only as forecasting practices that “do not replace the importance of empiricism.”

What Scrum is not

• Not a step-by-step method. The guide gives rules for how people relate and interact, and deliberately leaves out detailed instructions.
• Not something you can take half of. The guide says implementing only parts of Scrum is possible, but “the result is not Scrum.”
• Not the same as agile. Agile is a set of values and principles; Scrum is one framework that follows them. Agile project management explains the difference, and agile vs waterfall the older alternative.

When a small team should use Scrum, and when Kanban fits better

Scrum earns its meetings when your work is a product with a roadmap, you can plan two to four weeks ahead, stakeholders want to see progress on a regular rhythm, and you have enough people to fill the accountabilities, even part-time. Kanban fits better when work arrives unplanned (support, fixes, client requests), when you are two or three people, or when Sprint plans keep being torn up. The Kanban Guide↗ (opens in a new tab) names no roles and no events, so it adds no overhead to a team that is already stretched. Kanban vs Scrum has the full comparison and a decision guide, and what is Scrumban covers the hybrid.

Running Scrum on a simple board

To be plain: fenbs is not a Scrum tool. A board has four fixed lanes, To Do, Next Up, In Progress and Completed, and it has no sprints, no due dates, no story points, no burndown chart and no assignee field you can set. A small team can still run Scrum on it by mapping the pieces:

• To Do is the Product Backlog, ordered by priority from 1 to 10, where 1 is the most urgent. Next Up is the Sprint Backlog, and Completed means the task met your Definition of Done.
• Each task has a note for the problem, a plan for how it will be done, a test status with test notes, and an optional size from XS to XL, which gives refinement and the Definition of Done somewhere to land.
• Working agreements such as the Definition of Done go on the Decisions and rules page. A rule is a decision that holds from now on, the decider is always a person, and every connected AI assistant reads the rules before it starts work.
• History records who changed what on every task, including moves between lanes and which AI assistant made them, which is the evidence a Retrospective needs.

The Sprint dates live in your calendar, and the Sprint Goal can go in the board’s AI context, which everyone on the board and every connected assistant can read. If your team relies on generated Sprint reports or velocity charts, a dedicated Scrum tool will serve you better.