Scrum is a lightweight framework for developing, delivering and sustaining complex products through iterative and incremental work. It originated in the software-development community but is described more broadly as a framework for complex product development and other complex work. Scrum is based on empiricism, meaning that knowledge is derived from experience and decisions are made using observation, inspection and adaptation.
The framework organises work into fixed-length Sprints, generally lasting one month or less, during which a Scrum Team creates a usable Increment that meets its Definition of Done. Scrum defines three accountabilities: Product Owner, Scrum Master and Developers. It also defines three artefacts: Product Backlog, Sprint Backlog and Increment, with commitments associated with those artefacts. Scrum includes five formal events: the Sprint, Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective. These elements form a coherent framework rather than a menu from which teams can arbitrarily select whichever practices they prefer. The current official Scrum Guide is maintained by Ken Schwaber and Jeff Sutherland, who originally developed Scrum.
Scrum's name was inspired by a 1986 Harvard Business Review article by Hirotaka Takeuchi and Ikujiro Nonaka describing a product-development approach in which teams worked together like a rugby scrum, moving forward as a unit. Jeff Sutherland and Ken Schwaber later developed Scrum as a framework for software development, with early implementations emerging in the 1990s. The framework was subsequently refined through experience and formalised in successive versions of the Scrum Guide.
Scrum became one of the most widely recognised Agile approaches, although it is important to distinguish the framework itself from the many commercial certifications, scaling systems, consulting practices and organisational models that use the Scrum name. Scrum does not prescribe a complete software-engineering method, programming language, architecture, estimation technique or project-management system. It establishes accountabilities, events, artefacts and rules intended to support empirical product development, leaving teams substantial discretion over the technical practices they use to create the Increment.
The Product Owner is accountable for maximising the value of the product resulting from the work of the Scrum Team and for effective Product Backlog management. This includes developing and communicating the Product Goal, creating and clearly communicating Product Backlog items, ordering the Product Backlog and ensuring that it is transparent, visible and understood. The Product Owner is one person rather than a committee, although the role can involve collaboration with many stakeholders.
The Developers are the people on the Scrum Team committed to creating any aspect of a usable Increment each Sprint. They are accountable for creating the Sprint Backlog, instilling quality by adhering to the Definition of Done, adapting their plan each day towards the Sprint Goal and holding each other professionally accountable. The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide and for helping the Scrum Team and organisation understand and apply Scrum. These accountabilities should not be confused with conventional job titles; one person can have an existing organisational title while holding a Scrum accountability.
The Product Backlog is an ordered, emergent list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team and evolves as more is learned about the product and its environment. During Sprint Planning, the Scrum Team establishes a Sprint Goal, selects Product Backlog items that help achieve it and creates a plan for delivering the resulting work.
The selected items and the plan constitute the Sprint Backlog, which remains adaptable as the team learns during the Sprint, provided changes do not endanger the Sprint Goal. The Increment is a concrete stepping stone towards the Product Goal and must be usable. Multiple Increments can be created within a Sprint, and an Increment may be delivered to stakeholders before the Sprint Review. The Definition of Done is a formal description of the state of the Increment when it meets required quality measures. It creates a shared quality threshold and prevents teams from presenting incomplete work as finished.
The five Scrum events create regular opportunities for inspection and adaptation. The Sprint provides a consistent container for producing an Increment and establishing a useful rhythm. Sprint Planning initiates the Sprint by addressing why the Sprint is valuable, what can be done and how the selected work will be achieved.
The Daily Scrum is a short event for Developers to inspect progress towards the Sprint Goal and adapt their plan as necessary; it is not intended simply as a status meeting for a manager. The Sprint Review provides an opportunity for the Scrum Team and stakeholders to inspect the outcome and discuss future adaptations based on what has been learned. The Sprint Retrospective focuses on improving quality and effectiveness by examining people, interactions, processes, tools and the Definition of Done. These events are designed to make important information visible at regular intervals. Skipping them can reduce the framework's empirical feedback loops, although merely holding meetings without meaningful inspection and adaptation also fails to achieve their purpose.
Scrum's underlying theory rests on three pillars of empiricism: transparency, inspection and adaptation. Transparency requires that important aspects of the process be visible to those responsible for outcomes. Inspection involves examining artefacts and progress frequently enough to detect undesirable variances. Adaptation means adjusting the process or work when inspection reveals that the result or process is outside acceptable boundaries. Scrum also identifies five values: Commitment, Focus, Openness, Respect and Courage. These values describe behaviours that support the framework's operation.
Scrum is not a guarantee that a team will deliver valuable products, because empiricism only improves decision-making when the organisation provides meaningful objectives, reliable information and competent execution. A team can perform Scrum events correctly while still working on the wrong product or receiving contradictory strategic direction. Scrum therefore addresses a particular management problem—complex work under uncertainty—but it does not substitute for product strategy, technical expertise, customer research or organisational governance.
Scrum has common implementation problems when organisations treat it as a collection of ceremonies rather than an empirical framework. Daily Scrum can become a manager-facing status report; Sprint Planning can become a fixed task assignment exercise; Sprint Review can become a presentation with no stakeholder inspection; and Retrospective can become a repetitive complaint session without experimentation. Product Owners can also be overloaded with conflicting stakeholder demands or lack authority over ordering decisions.
Teams may split Developers into separate functional silos, undermining the cross-functional structure. Another frequent misunderstanding is that a Sprint is a deadline for completing a fixed quantity of work rather than a period for pursuing a Sprint Goal while adapting the plan. Scrum also does not require story points, burndown charts, velocity, user stories or planning poker. These may be used by teams, but they are not fundamental Scrum elements. This distinction is important because adding practices does not automatically make an implementation more compliant or effective.
Scrum is most directly useful when a team is developing or evolving a complex product where requirements and solutions cannot be fully determined in advance. It provides a relatively small framework for creating a recurring cycle of planning, execution, inspection and adaptation. Scrum differs from traditional project management because its primary structure is oriented towards ongoing product development rather than a fixed temporary project with a predetermined scope, although Scrum teams can operate within project environments.
It differs from Kanban because Scrum defines accountabilities, events and artefacts, whereas Kanban focuses on managing flow and does not prescribe the same role structure or Sprint cadence. Scrum can incorporate Kanban practices, and teams can use flow metrics alongside Scrum. Its practical significance lies in creating transparency around work and outcomes while giving the team repeated opportunities to adapt. Its effectiveness ultimately depends on whether the organisation respects the framework's empirical foundations rather than using Scrum terminology while retaining decision-making structures that prevent inspection, adaptation or meaningful team autonomy.
