Agile is not a tool, a certification, or a management style. At its foundation, it is a set of values and principles — and in the case of Scrum, a lightweight framework with a precise definition. The official Scrum Guide, authored by Ken Schwaber and Jeff Sutherland (the creators of Scrum), is the authoritative source. The most recent version was released in November 2020 and is available at https://scrumguides.org. Understanding what the guide actually defines — rather than common adaptations of it — is the starting point for any team that wants Agile delivery to work in practice.
What Scrum Actually Is
The 2020 Scrum Guide defines Scrum as a lightweight framework that helps people, teams, and organisations generate value through adaptive solutions for complex problems. The emphasis on lightweight is deliberate. The guide is short — fewer than 15 pages — because it intentionally avoids prescribing specific practices. Teams are expected to add processes and techniques suited to their context on top of the framework.
The Scrum Guide is explicit that Scrum is not a process or a technique for building products. It is a framework within which you can employ various processes and techniques. This distinction matters: teams that treat Scrum as a rigid checklist typically get less value from it than teams that understand its intent.
The framework has three categories of components: accountabilities (roles), events, and artifacts. Each element serves a specific purpose and omitting elements — even informally — undermines the integrity of the framework as defined.
- Scrum is a lightweight framework, not a methodology or process
- Designed for complex work where requirements evolve and predictability is limited
- Three components: accountabilities (roles), events, and artifacts
- The Scrum Guide is intentionally minimal — teams add context-specific practices on top
The Scrum Team and Accountabilities
The 2020 update removed the concept of a separate "Development Team" and replaced it with a single Scrum Team composed of three accountabilities: the Product Owner, the Developers, and the Scrum Master. There are no sub-teams or hierarchies within a Scrum Team.
The Product Owner is accountable for maximising the value of the product and managing the Product Backlog. The Developers are the people doing the work — creating usable increments each Sprint. The Scrum Master is accountable for the Scrum Team's effectiveness, helping the team understand and enact Scrum, and removing impediments.
The 2020 Guide also introduced the concept of self-management, replacing the older "self-organisation." Where self-organisation described teams choosing "who and how to do work," self-management describes teams choosing "who, how, and what to work on" — a meaningful expansion of team autonomy.
- Three accountabilities: Product Owner, Developers, Scrum Master
- No sub-teams or hierarchies within a Scrum Team
- Product Owner manages the Product Backlog and product value
- Scrum Master enables team effectiveness and removes impediments
- Teams are self-managing: they decide who does what and how
Events: The Sprint and Its Ceremonies
The Sprint is the heart of Scrum. It is a fixed-length event of one month or less during which a usable, potentially releasable Increment is created. Sprints create predictability by ensuring inspection and adaptation of progress at least every calendar month.
Within each Sprint, four events occur: Sprint Planning (defining what can be done and how), the Daily Scrum (a 15-minute daily inspection of progress toward the Sprint Goal), the Sprint Review (inspecting the Increment with stakeholders), and the Sprint Retrospective (planning improvements to quality and effectiveness).
The 2020 Scrum Guide added commitments to each artifact to improve transparency: the Product Goal (committed to by the Product Backlog), the Sprint Goal (committed to by the Sprint Backlog), and the Definition of Done (committed to by the Increment). These commitments define what each artifact is working toward and what "done" means.
- Sprint: fixed-length, 1 month or less, produces a usable Increment
- Sprint Planning: define the Sprint Goal and plan the work
- Daily Scrum: 15-minute daily inspection of progress toward the Sprint Goal
- Sprint Review: inspect the Increment with stakeholders
- Sprint Retrospective: plan improvements to team effectiveness
- Each artifact has a commitment: Product Goal, Sprint Goal, Definition of Done
How We Apply This in Practice
Our two-week sprint rhythm aligns directly with the Scrum framework as defined. Clear Sprint Goals, a prioritised Product Backlog, a shared Definition of Done, and action-oriented retrospectives are not optional additions — they are part of what makes the framework work.
Where teams deviate from Scrum without understanding the trade-offs — skipping retrospectives, running sprints without Sprint Goals, or treating the Scrum Master role as purely administrative — they typically lose the transparency and adaptability that the framework is designed to produce. The Scrum Guide is available for free at https://scrumguides.org and is the appropriate reference for any team evaluating how their process compares to the defined framework.