Scrum is a framework for developing
and sustaining complex products. This
Guide contains the definition of Scrum.
Scrum (n): A framework within
which people can address
complex adaptive problems,
while productively and
creatively delivering products
of the highest possible value.
Difficult to master
simple to understand
Ken Schwaber and Jeff Sutherland developed Scrum;
the Scrum Guide is written and provided by them.
Together, they stand behind the Scrum Guide.
Scrum (n): A framework within which
people can address complex adaptive
problems, while productively and
creatively delivering products of the
highest possible value.
Difficult to master
Simple to understand
The Scrum framework consists of Scrum
Teams and their associated roles, events,
artifacts, and rules. Each component within
the framework serves a specific purpose
and is essential to Scrum’s success and
Scrum is founded on empirical process control theory, or empiricism. Empiricism
asserts that knowledge comes from experience and making decisions based on what is
known. Scrum employs an iterative, incremental approach to optimize predictability
and control risk.
Significant aspects of the process must
be visible to those responsible for the
Scrum users must frequently inspect Scrum
artifacts and progress toward a Sprint Goal to
detect undesirable variances.
If an inspector determines that one or
more aspects of a process deviate
outside acceptable limits, and that the
resulting product will be unacceptable,
the process or the material being
processed must be adjusted
The Scrum Team consists of a Product Owner, the Development
Team, and a Scrum Master.
The product Owner
The Product Owner is
responsible for maximizing the
value of the product and the
work of the Development Team.
The Product Owner is one person, not a committee.
The developer Team
The Development Team consists of professionals
who do the work of delivering a potentially
releasable Increment of “Done” product at the end
of each Sprint. Only members of the Development
Team create the Increment
Optimal Development Team size is small
enough to remain nimble and large
enough to complete significant work
within a Sprint. Fewer than three
Development Team members decrease
interaction and results in smaller
The Scrum master
The Scrum Master is responsible for ensuring
Scrum is understood and enacted. Scrum Masters
do this by ensuring that the Scrum Team adheres
to Scrum theory, practices, and rules.
Scrum Master Service to the Product Owner
Finding techniques, Helping the
Scrum, Understanding product
planning, Ensuring the Product Owner
Scrum Master Service to the Development Team
Coaching the Development Team, Helping the
Development Team to create high-value products.
Scrum Master Service to the Organization
Leading and coaching the organization ,
Planning Scrum, Helping employees and
stakeholders , Causing change
All events are time-boxed events, such that every
event has a maximum duration. Once a Sprint
begins, its duration is fixed and cannot be
shortened or lengthened. The remaining events
may end whenever the purpose of the event is
achieved, ensuring an appropriate amount of time
is spent without allowing waste in the process.
The heart of Scrum is a Sprint, a time-box of one month or
less during which a “Done”, useable, and potentially
releasable product Increment is created. Sprints best have
consistent durations throughout a development effort. A new
Sprint starts immediately after the conclusion of the previous
During the Sprint
No changes are made that would
endanger the Sprint Goal
Quality goals do not decrease;
Scope may be clarified and re-negotiated
between the Product Owner and Development
Team as more is learned.
Sprint Planning is time-boxed to a maximum of eight
hours for a one-month Sprint. For shorter Sprints, the
event is usually shorter. The Scrum Master ensures
that the event takes place and that attendants
understand its purpose. The Scrum Master teaches the
Scrum Team to keep it within the time-box.
The Sprint Goal is an objective set for the Sprint
that can be met through the implementation of
Product Backlog. It provides guidance to the
Development Team on why it is building the
Increment. It is created during the Sprint Planning
A Sprint Review is held at the end of the Sprint to
inspect the Increment and adapt the Product
Backlog if needed. During the Sprint Review, the
Scrum Team and stakeholders collaborate about
what was done in the Sprint
The Sprint Retrospective is an opportunity for the Scrum Team to
inspect itself and create a plan for improvements to be enacted during
the next Sprint. The Sprint Retrospective occurs after the Sprint Review
and prior to the next Sprint Planning. This is a three-hour time-boxed
meeting for one-month Sprints. For shorter Sprints, the event is usually
shorter. The Scrum Master ensures that the event takes place and that
attendants understand its purpose. The Scrum Master teaches all to
keep it within the time-box. The Scrum Master participates as a peer
team member in the meeting from the accountability over the Scrum
The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize
activities and create a plan for the next 24 hours. This is done by inspecting the work since the last
Daily Scrum and forecasting the work that could be done before the next one. The Daily Scrum is
held at the same time and place each day to reduce complexity. During the meeting, the
Development Team members explain:
The Product Backlog is an ordered list of everything that might be needed in the product and is the
single source of requirements for any changes to be made to the product.
The Product Backlog lists all features, functions, requirements, enhancements, and fixes that
constitute the changes to be made to the product in future releases. Product Backlog items have the
attributes of a description, order, estimate and value.
Monitoring Progress Toward a Goal
At any point in time, the total work remaining to reach a goal can
be summed. The Product Owner tracks this total work remaining
at least every Sprint Review. The Product Owner compares this
amount with work remaining at previous Sprint Reviews to assess
progress toward completing projected work by the desired time
for the goal. This information is made transparent to all
The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for
delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the
Development Team about what functionality will be in the next Increment and the work needed to
deliver that functionality into a “Done” Increment.
The Increment is the sum of all the Product Backlog items completed during a Sprint and the value
of the increments of all previous Sprints
Scrum relies on transparency. Decisions to
optimize value and control risk are made based on
the perceived state of the artifacts. To the extent
that transparency is complete, these decisions
have a sound basis
Definition of “Done”
When a Product Backlog item or an Increment is described as “Done”,
everyone must understand what “Done” means. Although this varies
significantly per Scrum Team, members must have a shared understanding of
what it means for work to be complete, to ensure transparency. This is the
definition of “Done” for the Scrum Team and is used to assess when work is
complete on the product Increment.
Scrum is free and offered in this Guide. Scrum’s roles, artifacts, events, and rules are immutable and
although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in
its entirety and functions well as a container for other techniques, methodologies, and practices.