Scrum is a lightweight framework within which people can address complex, adaptive problems while delivering products of the highest possible value. That is the Scrum Guide's definition, and it is a good one — though it requires unpacking to be useful.

The key word is "framework." Scrum does not tell you how to do your work in detail. It provides a structure of roles, events, and artefacts within which teams can organise themselves and continuously improve. The framework is intentionally minimal: small enough to fit in a document, opinionated enough to be meaningful.

Where it came from

Jeff Sutherland and Ken Schwaber created Scrum in the early 1990s, drawing on earlier work by Takeuchi and Nonaka, who had studied leading product development organisations and coined the "Scrum" rugby metaphor in a 1986 Harvard Business Review article. The observation was that top-performing development teams moved like rugby forwards — as a unit, continuously adapting, rather than passing a baton in a relay race. Sutherland and Schwaber formalised this into a practical framework.

The three accountabilities

Scrum defines three accountabilities within a Scrum Team.

The Product Owner is accountable for the value the team delivers. This means owning and ordering the Product Backlog — the list of everything that might be needed in the product — and ensuring that the most valuable work is always at the top. The Product Owner is one person, not a committee, and their decisions must be respected by the organisation for the accountability to function.

The Scrum Master is accountable for the team's effectiveness. They help everyone understand and apply Scrum — not as a rulebook enforcer, but as a coach who helps the team continuously improve how it works. They also serve the organisation, helping it understand what Scrum requires and removing structural obstacles to the team's performance.

The Developers are the people who do the work: creating a usable Increment each Sprint. They self-organise around how to do the work — decisions about approach and method belong to the people closest to the work, not to managers or the Scrum Master.

The five events

The Sprint is the container for everything else — a fixed period of one month or less within which the team creates a usable Increment. Sprints run continuously; one ends and the next begins immediately.

Sprint Planning opens each Sprint. The team determines what they will deliver and how, anchored by a Sprint Goal that gives the Sprint its purpose.

The Daily Scrum is fifteen minutes each day for Developers to inspect progress toward the Sprint Goal and adapt their plan for the next twenty-four hours.

The Sprint Review closes the Sprint's delivery: the team and stakeholders inspect what was built and collaborate on what should come next.

The Sprint Retrospective closes the Sprint: the team reflects on how they worked and identifies specific improvements for the next Sprint.

The three artefacts

The Product Backlog is the ordered list of everything that might be valuable to build — owned by the Product Owner, never complete.

The Sprint Backlog is the subset of the Product Backlog selected for the current Sprint, plus the team's plan for delivering it.

The Increment is the sum of all completed work — everything delivered so far, combined into something usable. Work that does not meet the Definition of Done is not part of the Increment.

Why Scrum works — and when it doesn't

Scrum works by creating short feedback cycles. Rather than spending six months building something and discovering at the end that it missed the mark, you build something small every Sprint, show it to real stakeholders, learn from their response, and adjust. The framework makes the cost of being wrong visible early, when it can still be addressed.

Scrum tends not to work when it is implemented as ceremony without substance — when the meetings happen but the underlying decisions are still being made by management, when the Product Owner has no real authority, or when the Retrospective is treated as a check-box rather than a genuine improvement conversation. The framework is only as valuable as the honesty with which it is practiced.