What is Scrum? Roles, Events and Artifacts Explained Simply
Scrum is a lightweight framework for building products in short, repeating cycles called Sprints. Instead of planning an entire project up front and hoping the plan survives, a Scrum team delivers a small, usable slice of the product every one to four weeks, inspects the result, and adjusts course. That inspect-and-adapt loop is the whole point — everything else in Scrum exists to make it happen reliably.
The three accountabilities
The 2020 Scrum Guide defines three accountabilities (formerly called roles) on every Scrum team:
- Product Owner — owns the Product Backlog and is accountable for maximising the value of the work. One person, not a committee.
- Scrum Master — accountable for the team's effectiveness. Coaches the team in self-management, removes impediments, and helps the wider organisation understand empirical ways of working.
- Developers — everyone who does the work of creating the Increment, whatever their specialty. They own the Sprint Backlog and decide how the work gets done.
The five events
- The Sprint — the container for all other events: a fixed timebox of one month or less in which a usable Increment is created.
- Sprint Planning — the team agrees a Sprint Goal, selects Product Backlog items, and plans how to deliver them.
- Daily Scrum — 15 minutes for Developers to inspect progress toward the Sprint Goal and adapt the day's plan.
- Sprint Review — the team and stakeholders inspect the Increment and adapt the Product Backlog.
- Sprint Retrospective — the team inspects how the Sprint went and commits to concrete improvements.
The three artifacts
Each artifact carries a commitment that keeps it honest:
- Product Backlog → committed to the Product Goal, the long-term objective.
- Sprint Backlog → committed to the Sprint Goal, the single objective of the current Sprint.
- Increment → committed to the Definition of Done, the quality bar every piece of work must meet.
Why Scrum works
Scrum is built on empiricism: transparency, inspection and adaptation. Complex work — the kind where more is unknown than known — can't be fully planned in advance. Scrum accepts that and replaces prediction with frequent evidence: a working Increment every Sprint. Small batches reduce risk, short feedback loops catch bad assumptions early, and a stable team rhythm makes delivery measurable.
Where teams go wrong
Most "Scrum isn't working for us" stories trace back to a few patterns: no real Product Owner (five stakeholders with veto power instead), Sprints that never produce a usable Increment, a Definition of Done that quietly excludes testing, or a Daily Scrum run as a status report to a manager. Scrum makes these dysfunctions visible quickly — which is uncomfortable, and exactly the point.
How to get started
Formal training is the fastest route to doing Scrum properly rather than adopting the vocabulary and keeping old habits. The two most recognised entry certifications are the Certified ScrumMaster (CSM) from Scrum Alliance — a live two-day course with the exam included — and the Professional Scrum Master (PSM I) from Scrum.org. Our CSM certification guide walks through the syllabus, exam format and costs in detail.
Frequently asked questions
Is Scrum only for software teams?
No. Scrum originated in software but is used in marketing, hardware, research, education and operations — anywhere work is complex enough that plans need frequent correction.
How long should a Sprint be?
One month or less. Two weeks is the most common choice: long enough to build something meaningful, short enough that feedback arrives before much is wasted.
Is Scrum the same as Agile?
Agile is a set of values and principles from the Agile Manifesto; Scrum is one concrete framework that puts those values to work. Kanban, XP and SAFe are others.