This document provides an overview of the Scrum framework for developing software. Some key points:
- Scrum is an empirical, lightweight framework that helps teams generate value through adaptive solutions to complex problems. It is based on empiricism, lean thinking, and values transparency, inspection, and adaptation.
- Scrum uses events like sprints, daily stand-ups, sprint reviews and retrospectives to inspect and adapt its processes. Sprints are time-boxed periods for delivering increments of work toward a sprint goal.
- Scrum teams are cross-functional and consist of developers, a product owner, and scrum master. The product owner manages the product backlog and maximizes value. The scrum
7. Scrum Theory
Combines four formal events for
inspection and adaptation within
a containing event, the Sprint
Events implement the empirical
Scrum pillars of transparency,
inspection, and adaptation
11. Transparency enables inspection
Inspection without transparency
is misleading and wasteful
12. Inspection
Scrum artifacts and the progress
toward agreed goals must be
inspected frequently and
diligently to detect potentially
undesirable variances or
problems
13. Inspection enables adaptation
Inspection without adaptation
is considered pointless
14. Adaptation
If the resulting product is
unacceptable, the process being
applied or the materials being
produced must be adjusted
15. Adjustment must be made as
soon as possible to minimize
further deviation
20. Scrum Teams
Responsible for all product-
related activities from
stakeholder collaboration,
verification, maintenance,
operation, experimentation,
R & D and anything else
that might be required
22. Developers
Committed to creating any
aspect of a usable
Increment each Sprint
specific skills needed by the
Developers are often broad
and will vary with the
domain of work
23. Developers are always accountable for
Creating a plan for the print, the
Sprint Backlog
Instilling quality by adhering to a
Definition of Done
Adapting their plan each day
toward the Sprint Goal
Holding each other accountable as
professionals
24. Product Owner
Is accountable for
maximizing the value of
the product resulting from
the work of the Scrum
Team
25. Product Owner is also
accountable for effective
Product Backlog
management
Represent the needs of
many stakeholders in the
Product Backlog
26. Effective Product Backlog management
includes
Developing and explicitly
communicating the Product Goal
Creating and clearly
communicating Product Backlog
items
Ordering Product Backlog items
Ensuring that the Product Backlog
is transparent, visible and
understood
27. Scrum Master
Accountable for the Scrum
Team’s effectiveness by
enabling the Scrum Team to
improve its practices, within
the Scrum framework
28. Scrum Master serves the product owner by
helping
To find techniques for effective
Product Goal definition
The Scrum Team understand the
need for clear and concise
Product Backlog items
Establish empirical product
planning
Facilitating stakeholder
collaboration as requested
29. Scrum Master serves the Organization by helping
Leading, training, and
coaching the organization in
its Scrum adoption
Planning and advising Scrum
implementations
Helping employees and
stakeholders
Removing barriers between
stakeholders and Scrum
Teams
30. Scrum Events
Is a formal opportunity to
inspect and adapt Scrum
artifacts
Used in Scrum to create
regularity and to minimize the
need for meetings not
defined in Scrum
31. The Sprint
Are the heartbeat of Scrum,
where ideas are turned into
value
Enable predictability by
ensuring inspection and
adaptation of progress toward
a Product Goal at least every
calendar month
32. During the Sprint
No changes are made that
would endanger the Sprint
Goal
Quality does not decrease
Product Backlog is refined as
needed
Scope may be clarified and
renegotiated with the Product
Owner as more is learned
33. A Sprint could be cancelled if
the Sprint Goal becomes
obsolete
Only the Product Owner has
the authority to cancel the
Sprint
34. Sprint Planning
Initiates the Sprint by laying
out the work to be
performed for the Sprint
The Scrum Team invite
other people to attend
Sprint Planning to provide
advice
35. Daily Scrum
Purpose is to inspect
progress toward the Sprint
Goal and adapt the Sprint
Backlog as necessary,
adjusting the upcoming
planned work
36. Daily Scrum
Daily Scrums improve
communications, identify
impediments, promote
quick decision-making, and
consequently eliminate the
need for other meetings
37. Sprint Review
Purpose is to inspect the
outcome of the Sprint and
determine future
adaptations
It is a working session and
the Scrum Team should
avoid limiting it to a
presentation
38. Sprint Review
It is the second to last event
of the Sprint and is
timeboxed to a maximum of
four hours for a one-month
Sprint
39. Sprint Retrospective
Purpose is to plan ways to
increase quality and
effectiveness
It concludes the Sprint
It is timeboxed to a
maximum of three hours for
a one- month Sprint
40. Scrum Artifacts
Represent work or value
Designed to maximize
transparency of key information
Contains a commitment to ensure
it provides information that
enhances transparency and focus
product goal and sprint goal
41. Product Backlog
Is an emergent, ordered list
of what is needed to
improve the product
The single source of work
undertaken by the Scrum
Team
42. Product Backlog is
Refinement is the act of
breaking down and further
defining Product Backlog
items into smaller more
precise items
43. Commitment: Product Goal
Describes a future state of
the product which can serve
as a target for the Scrum
Team to plan against
The Product Goal is the
long-term objective for the
Scrum Team
44. Sprint Backlog
Is composed of the Sprint
Goal (why), the set of
Product Backlog items
selected for the Sprint
(what), as well as an
actionable plan for
delivering the Increment
(how)
45. Commitment: Sprint Goal
Is a commitment by the
Developers, it provides
flexibility in terms of the
exact work needed to
achieve it
Is created during the Sprint
Planning event and then
added to the Sprint Backlog
46. Increment
Is a concrete stepping stone
toward the Product Goal
Each Increment is additive
to all prior Increments and
thoroughly verified,
ensuring that all Increments
work together
47. Commitment: Definition of Done
Is a formal description of the
state of the Increment when it
meets the quality measures
required for the product
Creates transparency by
providing everyone a shared
understanding of what work
was completed as part of the
Increment